* Re: [PATCH 3/4] pack-objects: don't traverse objects unnecessarily
From: Dan McGee @ 2011-11-09 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk47qxe9x.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 5:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
>> Two optimizations take place here- we can start our objects array
>> iteration from a known point where we left off before we started trying
>> to find our tags,
>
> This I would understand (but I am somewhat curious how much last_untagged
> would advance relative to nr_objects for this half of the optimization to
> be worth it), but...
First off, sorry I wasn't able to respond to you until now, I've been
a bit swamped with other projects. I saw this made it into the 1.7.7.3
maint release today, but wanted to at least try to respond to the
points you raised (if you didn't investigate them by yourself
already).
If I remember right, the last_untagged optimization was pretty minor-
around 10% advancement of the pointer, never that much more. However,
it was a very easy change to make so I figured it was worth the slight
additional code (~5 lines changed for that part on its own).
>
>> and we don't need to do the deep dives required by
>> add_family_to_write_order() if the object has already been marked as
>> filled.
>
> I am not sure if this produces the identical result that was benchmarked
> in the original series.
I was not either when I wrote the patch, and I had hoped to confirm
the results you showed in the message of 1b4bb16b9ec. However, I was
unable to figure out how you generated those numbers so I wasn't able
to do so (and had planned to get back to you to find out how you made
those tables). Were you able to verify the ordering did not regress?
> For example, if you have a tagged object that is not a commit (say a
> blob), you would have written that blob in the second phase (write tagged
> objects together), so the family of blobs that share same delta parent as
> that blob will not be written in this "Finally all the rest" in the right
> place in the original list, no?
True, I think. They would not be written in the same place, but is
that necessarily the right place? The delta parent of an
already-filled tag object would eventually come up in the array as not
filled, and then we would do a full deep dive at that point, so the
majority of the objects would still be in close proximity.
Note that either way, we still have a gap between the original tagged
object and its "family"- potentially all the other tagged tips, tags,
commits, and trees before the blobs are finally hit and laid out in
family groups. So there is at least one potentially big seek that
can't be avoided.
> I do not think this change would forget to fill an object that needs to be
> filled, but it would affect the resulting ordering of the list, so...
This was the purpose of the added "if (wo_end != nr_objects) die()"
line; it confirms we have traversed and hit every object we originally
found.
-Dan
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: Michael Haggerty @ 2011-11-09 5:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3E-YCMQQzJAU2wjjD-adpNy6bGb-=iUQ=p=bFTWxm+Ng@mail.gmail.com>
On 11/08/2011 12:34 PM, Felipe Contreras wrote:
> Has anybody seen these?
> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>
> Seems like a potential area of improvement.
The fact that git requires periodic garbage collection is indeed
annoying (even in interactive use) and even more annoying in the
scenario discussed by the author of this article.
With respect to the article's claims about the overall efficiency of
Mercurial vs. git, I would like to point out that the author's use of a
test repository with a linear history avoids one of Mercurial's big
design weaknesses. If the repository had had a branching history,
Mercurial's numbers would probably be significantly less flattering.
Mercurial's revlog repository format [1] (at least the last time I
checked) uses a single data file to hold the contents of all versions of
a single file in the working copy. It appends a delta to the end of the
revlog file for each revision, with periodic fulltexts. It is designed
to make it possible to reconstruct any file revision via a single seek
and a single read of at most twice the length of the file's fulltext
(assuming that the index is already known). The avoidance of disk seeks
goes a long way to explaining Mercurial's competitive performance
despite the fact that it is written in Python.
However, the deltas stored in revlog are not relative to a revision's
parent(s), but rather relative to the previous revision in the revlog
file, which is typically the most recent revision committed *to any
branch*. Therefore, revlog is very good at storing a linear series of
commits, but is considerably less efficient at storing a history with
lots of branches that were under development concurrently. The net
result is that the history of a branchy repository can take up much more
space than that of a linear repository.
There was a GSOC "parentdelta" project to allow deltas to be computed
against parents [2], later replaced by a second "generaldelta" scheme
[3], but AFAICT this is still experimental and they are struggling with
its performance.
There is also a script in contrib that reorders the revisions in a
revlog file to put topological neighbors closer together [4]. This can
shrink the size of the file dramatically. But of course this script is
something like "git gc" in the sense that it would presumably need to be
run periodically, and each run would have to lock the repo for some time.
All this is not to detract from the fact that Mercurial, by not
requiring garbage collection, has a big advantage against git in certain
scenarios.
Michael
[1]
http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.How_does_Mercurial_store_its_data.3F
[2] http://mercurial.selenic.com/wiki/ParentDeltaPlan
[3]
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_1.9_.282011-07-01.29
[4] http://selenic.com/hg/file/54c0517c0fe8/contrib/shrink-revlog.py
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] completion: don't leak variable from the prompt into environment
From: SZEDER Gábor @ 2011-11-09 10:02 UTC (permalink / raw)
To: git, Junio C Hamano, Shawn O. Pearce; +Cc: SZEDER Gábor
Commit e5b8eebc (completion: fix issue with process substitution not
working on Git for Windows, 2011-10-26) introduced a new variable in
__git_ps1_show_upstream(), but didn't declare it as local to prevent
it from leaking into the environment.
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b3571ab4..d18895b1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
local upstream=git legacy="" verbose=""
# get some config options from git-config
- output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
+ local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
while read key value; do
case "$key" in
bash.showupstream)
--
1.7.8.rc0.107.g695cb
^ permalink raw reply related
* Re: [PATCH v3 00/17] Pulling signed tags
From: Robin H. Johnson @ 2011-11-09 10:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
On Tue, Nov 08, 2011 at 05:01:46PM -0800, Junio C Hamano wrote:
> The third iteration of the fourth approach to give more confidence on the
> authenticity of history, but the third approach of giving GPG signature to
> individual commits is independently useful and has been rebased on top.
Looks good at initial visual review, I'll give a deep inspection in a
day or two (at ApacheCon this week).
Thanks for the perseverance!
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: git svn rebase bug
From: Carlos Martín Nieto @ 2011-11-09 10:40 UTC (permalink / raw)
To: Matt Arsenault; +Cc: git
In-Reply-To: <39110A70-A25E-4A6B-A401-FCCE895B2CE5@rpi.edu>
On Tue, Nov 08, 2011 at 03:50:25PM -0500, Matt Arsenault wrote:
> There seems to be a bug using git svn rebase with strategies
>
> git version 1.7.7.2
>
>
> $ git svn rebase --strategy=theirs
ENOENT. The "theirs" strategy doesn't exist (there is an "ours"
strategy). "Theirs" in a option to the recursive merge strategy.
>
> First, rewinding head to replay your work on top of it...
> /usr/lib/git-core/git-rebase--merge: line 69: git-merge-theirs: command not found
> Unknown exit code (127) from command: git-merge-theirs deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c^ -- HEAD deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c
> rebase --strategy=theirs refs/remotes/git-svn: command returned error: 1
The bug is the failure to detect that the merge strategy doesn't
exist, but your command wouldn't have worked anyway.
cmn
^ permalink raw reply
* [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Alexey Shumkin @ 2011-11-09 11:00 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano
In-Reply-To: <20111007201932.GC29712@elie.hsd1.il.comcast.net>
Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type header. Its charset
can be defined with hooks.emailcharset config variable.
NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
to display logs correctly.
Also, introduce hooks.gitopts config variable
with the default '-c core.quotepath=false'.
This takes into account that we want to see pretty email-message
with well-looking messages and list of changed filenames.
And usually non-ASCII filenames are in the same
encoding that commit messages are.
Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
---
contrib/hooks/post-receive-email | 43 ++++++++++++++++++++++++++-----------
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba077c1..913be89 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -65,6 +65,14 @@
# Default is "--stat --summary --find-copies-harder". Add -p to those
# options to include a unified diff of changes in addition to the usual
# summary output.
+# hooks.gitopts
+# git options for the git diff-tree invocation that shows changes.
+# Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
+# used in a project.
+# hooks.emailcharset
+# The charset used in Content-Type header. UTF-8, if not specified.
+# It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
+# which expects i18n.logOutputEncoding to be set to UTF-8)
#
# Notes
# -----
@@ -234,6 +242,9 @@ generate_email_header()
cat <<-EOF
To: $recipients
Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+ MIME-Version: 1.0
+ Content-Type: text/plain; charset=$emailcharset
+ Content-Transfer-Encoding: 8bit
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
@@ -241,7 +252,7 @@ generate_email_header()
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
- the project "$projectdesc".
+ the project "$projectdesc_e".
The $refname_type, $short_refname has been ${change_type}d
EOF
@@ -255,7 +266,7 @@ generate_email_footer()
hooks/post-receive
--${SPACE}
- $projectdesc
+ $projectdesc_e
EOF
}
@@ -451,7 +462,7 @@ generate_update_branch_email()
# non-fast-forward updates.
echo ""
echo "Summary of changes:"
- git diff-tree $diffopts $oldrev..$newrev
+ git $gitopts diff-tree $diffopts $oldrev..$newrev
}
#
@@ -656,14 +667,15 @@ show_new_revisions()
revspec=$oldrev..$newrev
fi
+ revlistopts="-c i18n.logOutputEncoding=$emailcharset"
other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ |
grep -F -v $refname)
git rev-parse --not $other_branches |
if [ -z "$custom_showrev" ]
then
- git rev-list --pretty --stdin $revspec
+ git $revlistopts rev-list --pretty --stdin $revspec
else
- git rev-list --stdin $revspec |
+ git $revlistopts $rev-list --stdin $revspec |
while read onerev
do
eval $(printf "$custom_showrev" $onerev)
@@ -714,14 +726,6 @@ if [ -z "$GIT_DIR" ]; then
exit 1
fi
-projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
-# Check if the description is unchanged from it's default, and shorten it to
-# a more manageable length if it is
-if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
-then
- projectdesc="UNNAMED PROJECT"
-fi
-
recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
@@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
maxlines=$(git config hooks.emailmaxlines)
diffopts=$(git config hooks.diffopts)
: ${diffopts:="--stat --summary --find-copies-harder"}
+gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
+emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
+
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
+# Check if the description is unchanged from it's default, and shorten it to
+# a more manageable length if it is
+if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
+then
+ projectdesc="UNNAMED PROJECT"
+fi
+# Leave description in UTF-8 to be used in the Subject header
+# But convert it to an hooks.emailcharset encoding to be used in a message body
+projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.7.7.3.5.g55178
^ permalink raw reply related
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-11-09 11:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAGdFq_jPfSFidb59m-5Tsyusw3yQFRnxU9nqBVosVPuzbt86GA@mail.gmail.com>
On Wed, Nov 9, 2011 at 12:27 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Wed, Nov 9, 2011 at 01:24, Vitor Antunes <vitor.hda@gmail.com> wrote:
>>
>> That was exactly my intention when I used release_tree_entry(). But I
>> guess I'm doing it wrong, because without the delete_ref() part this
>> does not work (just noticed there's a missing semicolon there...
>> sorry). Any advices/guidance, please? :)
>
> ENODATA. What do you mean with "does not work"? Can you run it through
> gdb and see what's going on?
Calm down! It's not that bad to require gdb :)
It just means that even using the drop() command from the patch I
posted before, I still get the "new tip ... does not contain
..." error from fast-import.
--
Vitor Antunes
^ permalink raw reply
* Problem with git-svn with limited SVN access
From: Antoine Bonavita @ 2011-11-09 11:28 UTC (permalink / raw)
To: git
Hello,
I have a problem with a git-svn setup and although I spent most of
yesterday googling for a solution but did not find any (see below for my
failed attempts). I hope you guys here will be able to help me.
I have limited access to a SVN repository with a "standard" layout. By
limited, I mean that I am allowed only to access the folders "trunk",
"branches/XXX" and "branches/YYY".
*Attempt 1:*
> git svn init svn://server/aaa/AAA -T trunk -b branches --username=UUU
Initialized empty Git repository in /home/.../.git/
Using higher level of URL: svn://server/aaa/AAA => svn://server/aaa
> git svn fetch
Error from SVN, (220001): Item is not readable: Item is not readable
*Attempt 2:*
> git svn init svn://server/aaa/AAA -T trunk -b branches --username=UUU
--no-minimize-url
Initialized empty Git repository in /home/.../.git/
> git svn fetch
W: Item is not readable: Item is not readable at
/usr/libexec/git-core/git-svn line 1782
Error from SVN, (220001): Item is not readable: Item is not readable
*Attempt 3:*
> git svn init svn://server/aaa/AAA -T trunk --username=UUU
--no-minimize-url
Initialized empty Git repository in /home/.../.git/
> git svn fetch
W: Item is not readable: Item is not readable at
/usr/libexec/git-core/git-svn line 1782
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/AAA/trunk'
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
Read access denied for root of edit: Not authorized to open root of edit
operation at /usr/libexec/git-core/git-svn line 5131
*Attempt 4:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
> git svn fetch
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/AAA/trunk'
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
### stuff actually retrieved from SVN
.....
r6035 = 6163cb28acff14d68f1b96869274b668405897a2 (refs/remotes/trunk)
.....
Compressing objects: 100% (10751/10751), done.
Writing objects: 100% (10886/10886), done.
Total 10886 (delta 9331), reused 0 (delta 0)
Checking out files: 100% (6002/6002), done.
Checked out HEAD:
svn://server/aaa/AAA/trunk r27316
creating empty directory: lib/AAA/mp3gain/otherlang/help
...
### No line with any branch. So it looks like I managed to get the trunk
but not the branches.
*Attempt 5:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
### My .git/config looks like:
[svn-remote "svn"]
url = svn://server/aaa/AAA/trunk
fetch = :refs/remotes/trunk
### If I try to add one of the branches manually:
branches = branches/XXX:refs/remotes/branches/XXX
> git svn fetch
One '*' is needed in glob: 'branches/XXX'
*Attempt 6:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
### I put a glob instead of the branch name in git/.config:
branches = branches/{XXX,YYY}:refs/remotes/branches/*
> git svn fetch
...
Counting objects: 10886, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10751/10751), done.
Writing objects: 100% (10886/10886), done.
Total 10886 (delta 9330), reused 0 (delta 0)
error: Untracked working tree file 'COPYRIGHT.txt' would be overwritten
by merge.
read-tree -m -u -v HEAD HEAD: command returned error: 128
### Only refs/remotes/trunk checked out. No branch.
At this point, I'm really lost and running out of ideas. If someone
could help me with this, I would be very grateful.
Please forgive me if I posted to the wrong mailing-list but I could not
find a specific git-svn list. If there is such thing, please point me in
the right direction.
Thanks,
Antoine.
--
Antoine Bonavita (antoine@stickyadstv.com)
Envoyé de mon PC. Moi je suis Fedora.
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: David Michael Barr @ 2011-11-09 12:34 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Felipe Contreras, git
In-Reply-To: <20111108215812.GB18529@sigill.intra.peff.net>
On Wed, Nov 9, 2011 at 8:58 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 08, 2011 at 10:40:15AM -0600, Brandon Casey wrote:
>
>> On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>> > Has anybody seen these?
>> > http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>> >
>> > Seems like a potential area of improvement.
>>
>> I think this is a case of designing the problem space so that your
>> intended winner wins and your intended loser loses.
>
> Sort of. It is a real problem space, and mercurial does have some
> advantage in that area.
[...]
> So he may have a point that mercurial might perform better for some
> metrics than git in the current state. But I think a lot of that is
> because nobody has bothered putting git into this situation and done the
> tweaks needed to make it fast. You can argue that git sucks because it
> needs tweaking, of course, but if I were picking between the two systems
> to implement something like this, I'd consider picking git and doing the
> tweaks (of course, I'm far from unbiased).
It is the case that the default behaviour of git gc --auto is far from optimal.
I've been playing with ways to achieve both better asymptotic
performance and less jitter.
One part of that is choosing "good" packing parameters for a given repo.
I did this in a partially automated fashion for WebKit but I think the
process can be generalised.
The other issue is how often you repack ancient history, the potential
waste is obvious.
To this end I propose a repacking strategy in the spirit of merge-sort:
If you can maintain the constraint that the sizes of packs in a repo
form a geometric sequence, my napkin says the amortised cost of gc is
log(n).
--
David Barr.
^ permalink raw reply
* Re: [PATCH] completion: don't leak variable from the prompt into environment
From: Junio C Hamano @ 2011-11-09 13:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1320832970-26239-1-git-send-email-szeder@ira.uka.de>
SZEDER Gábor <szeder@ira.uka.de> writes:
> Commit e5b8eebc (completion: fix issue with process substitution not
> working on Git for Windows, 2011-10-26) introduced a new variable in
> __git_ps1_show_upstream(), but didn't declare it as local to prevent
> it from leaking into the environment.
> ---
Thanks; I'd consider this signed-off?
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b3571ab4..d18895b1 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
> local upstream=git legacy="" verbose=""
>
> # get some config options from git-config
> - output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> + local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> while read key value; do
> case "$key" in
> bash.showupstream)
^ permalink raw reply
* [PATCH 18/17] request-pull: use the annotated tag contents
From: Junio C Hamano @ 2011-11-09 13:20 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
The integrator tool will start allowing to pull signed or an annotated
tag, i.e.
$ git pull $there tags/for-linus
and the description in the tag is used to convey a meaningful message from
the lieutenant to the integrator to justify the history being pulled.
Include the message in the pull request e-mail, as the same information is
useful in this context, too. It would encourage the lieutenants to write
meaningful messages in their signed tags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Goes on top of jc/request-pull-show-head-4 that has been cooking in
the 'next' branch.
git-request-pull.sh | 14 ++++++++++++++
t/t5150-request-pull.sh | 4 ++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 626cf25..c6a5b7a 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -48,6 +48,8 @@ then
fi
fi
+tag_name=$(git describe --exact "$head^0" 2>/dev/null)
+
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
headrev=$(git rev-parse --verify "$head"^0) || exit
@@ -82,8 +84,20 @@ then
echo "(from the branch description for $branch local branch)"
echo
git config "branch.$branch_name.description"
+fi &&
+
+if test -n "$tag_name"
+then
+ git cat-file tag "$tag_name" |
+ sed -n -e '1,/^$/d' -e '/^-----BEGIN PGP /q' -e p
+ echo
+fi &&
+
+if test -n "$branch_name" || test -n "$tag_name"
+then
echo "----------------------------------------------------------------"
fi &&
+
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 5bd1682..ea6f692 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -86,6 +86,7 @@ test_expect_success 'setup: two scripts for reading pull requests' '
s/$downstream_url_for_sed/URL/g
s/for-upstream/BRANCH/g
s/mnemonic.txt/FILENAME/g
+ s/^version [0-9]/VERSION/
/^ FILENAME | *[0-9]* [-+]*\$/ b diffstat
/^AUTHOR ([0-9]*):\$/ b shortlog
p
@@ -201,6 +202,9 @@ test_expect_success 'pull request format' '
SUBJECT (DATE)
----------------------------------------------------------------
+ VERSION
+
+ ----------------------------------------------------------------
SHORTLOG
DIFFSTAT
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply related
* Re: [PATCH] completion: don't leak variable from the prompt into environment
From: SZEDER Gábor @ 2011-11-09 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vd3d1widd.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Nov 09, 2011 at 05:11:26AM -0800, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
>
> > Commit e5b8eebc (completion: fix issue with process substitution not
> > working on Git for Windows, 2011-10-26) introduced a new variable in
> > __git_ps1_show_upstream(), but didn't declare it as local to prevent
> > it from leaking into the environment.
> > ---
>
> Thanks; I'd consider this signed-off?
Oops, yeah, sorry.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Just for the record: I pointed this out when the patch was discussed
on the list, and proposed a better solution:
http://thread.gmane.org/gmane.comp.version-control.git/184229/focus=184290
but apparently only after that patch was already merged. Since we are
in -rc phase, this patch below chooses the less intrusive solution
(i.e. it declares the variable as local instead of eliminating it by
using the command substitution as here string).
Gábor
>
> > contrib/completion/git-completion.bash | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index b3571ab4..d18895b1 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
> > local upstream=git legacy="" verbose=""
> >
> > # get some config options from git-config
> > - output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> > + local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> > while read key value; do
> > case "$key" in
> > bash.showupstream)
^ permalink raw reply
* Re: [PATCH 19/17] merge: do not fast-forward when merging a tag
From: Junio C Hamano @ 2011-11-09 13:39 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7v8vnpwhxl.fsf@alter.siamese.dyndns.org>
Merging a signed or an annotated tag is meant to trigger the editor for
the integrator to leave a meaningful merge commit log in the history.
Disallow fast-forwarding the merge in such a case to ensure that a merge
commit is always recorded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/merge.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b3e374..99f1429 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1255,8 +1255,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strbuf_reset(&buf);
if (merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
- merge_remote_util(commit)->obj->type == OBJ_TAG)
+ merge_remote_util(commit)->obj->type == OBJ_TAG) {
option_edit = 1;
+ allow_fast_forward = 0;
+ }
}
if (!use_strategies) {
^ permalink raw reply related
* Re: [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Junio C Hamano @ 2011-11-09 14:11 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Johannes Sixt, Jonathan Nieder
In-Reply-To: <1320836458-24088-1-git-send-email-Alex.Crezoff@gmail.com>
Alexey Shumkin <alex.crezoff@gmail.com> writes:
> Some email clients (e.g. claws-mail) incorrectly display
> message body when there is no Content-Type header and charset
> explicitly defined.
> So, set explicitly Content-Type header. Its charset
> can be defined with hooks.emailcharset config variable.
>
> NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
> because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
> to display logs correctly.
>
> Also, introduce hooks.gitopts config variable
> with the default '-c core.quotepath=false'.
> This takes into account that we want to see pretty email-message
> with well-looking messages and list of changed filenames.
> And usually non-ASCII filenames are in the same
> encoding that commit messages are.
(style) Why such an extremely ragged looking line-wrap of paragraphs?
> Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> ---
In this space, please describe what happened during v1 and v2, and how is
this round different to help reviewers. Pointers to list archive, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/181737, would be
helpful.
People involved in v1/v2 discussion are missing from the Cc: line. Please
do not give a false impression that you are hiding from them.
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index ba077c1..913be89 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -65,6 +65,14 @@
> # Default is "--stat --summary --find-copies-harder". Add -p to those
> # options to include a unified diff of changes in addition to the usual
> # summary output.
> +# hooks.gitopts
> +# git options for the git diff-tree invocation that shows changes.
> +# Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
> +# used in a project.
We do not particularly appreciate a patch that does two unrelated things
("they are both related to post-receive-email" is not an argument).
Wouldn't this be useful even if the change to add hooks.emailcharset
turned out to be unwanted, or vice versa?
> +# hooks.emailcharset
> +# The charset used in Content-Type header. UTF-8, if not specified.
> +# It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
> +# which expects i18n.logOutputEncoding to be set to UTF-8)
Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?
> @@ -234,6 +242,9 @@ generate_email_header()
> cat <<-EOF
> To: $recipients
> Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
> + MIME-Version: 1.0
> + Content-Type: text/plain; charset=$emailcharset
> + Content-Transfer-Encoding: 8bit
> X-Git-Refname: $refname
> X-Git-Reftype: $refname_type
> X-Git-Oldrev: $oldrev
> ...
> @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
> maxlines=$(git config hooks.emailmaxlines)
> diffopts=$(git config hooks.diffopts)
> : ${diffopts:="--stat --summary --find-copies-harder"}
> +gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
> +emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
> +
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> +# Check if the description is unchanged from it's default, and shorten it to
> +# a more manageable length if it is
> +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> +then
> + projectdesc="UNNAMED PROJECT"
> +fi
> +# Leave description in UTF-8 to be used in the Subject header
> +# But convert it to an hooks.emailcharset encoding to be used in a message body
> +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)
Hmm, this generates a piece of e-mail whose subject line is in UTF-8
(without B/Q quoting) and message body is in totally different encoding.
Is it what mailers really want to see?
It almost seems backwards; converting the payload to UTF-8 and always
sending UTF-8 would be a simpler approach, methinks.
^ permalink raw reply
* Re: [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Alexey Shumkin @ 2011-11-09 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Jonathan Nieder
In-Reply-To: <7vy5vpv11n.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <alex.crezoff@gmail.com> writes:
>
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header. Its charset
> > can be defined with hooks.emailcharset config variable.
> >
> > NB: This above-mentioned charset may differ from
> > i18n.logOutputEncoding, because e.g. gitweb expects (for now)
> > i18n.logOutputEncoding set to UTF-8 to display logs correctly.
> >
> > Also, introduce hooks.gitopts config variable
> > with the default '-c core.quotepath=false'.
> > This takes into account that we want to see pretty email-message
> > with well-looking messages and list of changed filenames.
> > And usually non-ASCII filenames are in the same
> > encoding that commit messages are.
>
> (style) Why such an extremely ragged looking line-wrap of paragraphs?
I'm not good enough in English spelling ;(
>
> > Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> > ---
>
> In this space, please describe what happened during v1 and v2, and
> how is this round different to help reviewers. Pointers to list
> archive, e.g.
> http://thread.gmane.org/gmane.comp.version-control.git/181737, would
> be helpful.
>
> People involved in v1/v2 discussion are missing from the Cc: line.
> Please do not give a false impression that you are hiding from them.
Oh, I've missed that moment, sorry all
>
> > diff --git a/contrib/hooks/post-receive-email
> > b/contrib/hooks/post-receive-email index ba077c1..913be89 100755
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -65,6 +65,14 @@
> > # Default is "--stat --summary --find-copies-harder". Add -p to
> > those # options to include a unified diff of changes in addition
> > to the usual # summary output.
> > +# hooks.gitopts
> > +# git options for the git diff-tree invocation that shows
> > changes. +# Default is '-c core.quotepath=false' to be able to
> > see non-ASCII filenames +# used in a project.
>
> We do not particularly appreciate a patch that does two unrelated
> things ("they are both related to post-receive-email" is not an
> argument). Wouldn't this be useful even if the change to add
> hooks.emailcharset turned out to be unwanted, or vice versa?
The main reason was that using core.quotepath=false leads to showing
file names "correctly" according to commit messages encoding to make
email-message look pretty.
>
> > +# hooks.emailcharset
> > +# The charset used in Content-Type header. UTF-8, if not
> > specified. +# It can differ from i18n.logOutputEncoding (not to
> > mess-up with gitweb +# which expects i18n.logOutputEncoding to be
> > set to UTF-8)
>
> Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?
Well, you're right.
For the explanation:
AFAIU, such hooks are used on central servers to notify involved people
about changes. And AFAIU the same server repos are used with gitweb
(which AFAIK requires i18n.logOutputEncoding=UTF-8)
But in common case "i18n.logoutputencoding" is more suitable.
>
> > @@ -234,6 +242,9 @@ generate_email_header()
> > cat <<-EOF
> > To: $recipients
> > Subject: ${emailprefix}$projectdesc $refname_type
> > $short_refname ${change_type}d. $describe
> > + MIME-Version: 1.0
> > + Content-Type: text/plain; charset=$emailcharset
> > + Content-Transfer-Encoding: 8bit
> > X-Git-Refname: $refname
> > X-Git-Reftype: $refname_type
> > X-Git-Oldrev: $oldrev
> > ...
> > @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
> > maxlines=$(git config hooks.emailmaxlines)
> > diffopts=$(git config hooks.diffopts)
> > : ${diffopts:="--stat --summary --find-copies-harder"}
> > +gitopts=$(git config hooks.gitopts || echo '-c
> > core.quotepath=false') +emailcharset=$(git config
> > hooks.emailcharset || echo 'UTF-8') +
> > +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> > +# Check if the description is unchanged from it's default, and
> > shorten it to +# a more manageable length if it is
> > +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> > +then
> > + projectdesc="UNNAMED PROJECT"
> > +fi
> > +# Leave description in UTF-8 to be used in the Subject header
> > +# But convert it to an hooks.emailcharset encoding to be used in a
> > message body +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t
> > $emailcharset 2>/dev/null)
>
> Hmm, this generates a piece of e-mail whose subject line is in UTF-8
> (without B/Q quoting) and message body is in totally different
> encoding. Is it what mailers really want to see?
Here you're right, too. Windows email clients may interpret Subject
header without B/Q quoting in its default Windows charset, and as far as
it may contain non-English project description, so Subject would look
ugly. But I'll try to test with some clients.
>
> It almost seems backwards; converting the payload to UTF-8 and always
> sending UTF-8 would be a simpler approach, methinks.
Sounds reasonable
^ permalink raw reply
* [PATCH] gitk: use "gitk: repo-top-level-dir" as window title
From: Zbigniew Jędrzejewski-Szmek @ 2011-11-09 16:28 UTC (permalink / raw)
To: git, Doug Maxey, Paul Mackerras; +Cc: gitster, Zbigniew Jędrzejewski-Szmek
Previously, when run in a subdirectory, gitk would show the name
of this subdirectory as title, which was misleading. When run with
GIT_DIR set, it would show the cwd, which is even more misleading.
In case of non-bare repos, the .git suffix in the path is skipped.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
gitk-git/gitk | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..2eaf901 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -18,6 +18,14 @@ proc gitdir {} {
}
}
+proc reponame {} {
+ set n [file normalize [gitdir]]
+ if {[string match "*/.git" $n]} {
+ set n [string range $n 0 end-5]
+ }
+ return [file tail $n]
+}
+
# A simple scheduler for compute-intensive stuff.
# The aim is to make sure that event handlers for GUI actions can
# run at least every 50-100 ms. Unfortunately fileevent handlers are
@@ -11592,6 +11600,8 @@ if {[package vcompare $git_version "1.6.6.2"] >= 0} {
set show_notes "--show-notes"
}
+set appname "gitk"
+
set runq {}
set history {}
set historyindex 0
@@ -11656,7 +11666,7 @@ catch {
}
# wait for the window to become visible
tkwait visibility .
-wm title . "[file tail $argv0]: [file tail [pwd]]"
+wm title . "$appname: [reponame]"
update
readrefs
--
1.7.8.rc0.251.gccd63
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-09 17:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> No, no, don't consider my "put in the merge message" a winner at all.
>
> I personally dislike it, and don't really think it's a wonderful thing
> at all. I really does have real downsides:
>
> - internal signatures really *are* a disaster for maintenance. You
> can never fix them if they need fixing (and "need fixing" may well be
> "you want to re-sign things after a repository format change")
>
> - they are ugly as heck, and you really don't want to see them in
> 99.999% of all cases.
>
> So putting those things iin the merge commit message may have some
> upsides, but it has tons of downsides too.
>
> I think your refs/audit/ idea should be given real thought, because
> maybe that's the right idea.
With the latest round of touch-ups, modulo a few bugs I will be fixing
before the 1.7.8 final, I think what we have is more or less OK in the
shorter term and should be ready for general consumption. The ugliness is
gone, but the issue around internal signatures may remain to be solved in
the longer term. At least, by storing the full contents of the tag today
in an extended header, when we figure out how a detached signature should
really work, we could convert by extracting them from the history.
In a separate message earlier in the thread, you raised another issue.
> I hate how anonymous our branches are. Sure, we can use good names for
> them, but it was a mistake to think we should describe the repository
> (for gitweb), rather than the branch.
>
> Ok, "hate" is a strong word. I don't "hate" it. I don't even think
> it's a major design issue. But I do think that it would have been
> nicer if we had had some branch description model.
At the first glance, our branch model is indeed peculiar in that a branch
does not have a global identity. The scope of its name is local to the
repository, and it is just a pointer into the history. A "note" [*1*] that
can annotate a commit long after the commit is made is not a good way to
describe what a branch is about, because the tip of the branch can advance
beyond the commit that is annotated by such a note. A commit on a branch
does not serve as a good anchoring point to describe the branch.
However, a commit that merges the history of a branch, whether the merged
branch is from a local repository or from a remote one, does serve as a
good anchoring point. The work on a branch is finished as complete as
possible at the time of the merge, and the committer who merges the branch
agrees with both the objective and the implementation of the work done on
the branch, and that is why the merge is made [*2*]. Describing what the
history of the side branch was about in the resulting merge is a perfectly
sensible way to explain the branch. So in that sense, I am very happy with
the way the merge message template uses the pull request tag to let the
lieutenant explain and defend the history behind the tag used for the pull
request. Such an explanation does not have to be keyed with anybody's
local branch name (e.g. "for-linus" would mean different things for
different pull requests even from the same person), but keying it with the
resulting merge commit is a sensible way to leave the record in the
history.
After justifying with the above two paragraphs that it is perfectly
sensible to record the annotations on commits and not on "branch names", I
do agree that we would eventually want to be able to have such annotations
on commits after the fact. Neither "tags" nor "notes" is necessarily a
very good mechanism, however, for the purpose of "signed pull requests"
and "signed commits" [*3*]. Here are some pros and cons:
- tags must be named, but the only thing we need is to be able to look
the contents (with signature if signed) up given a commit object.
Unlike the usual "I want to check out v3.0 release" look-up that goes
from tag names to the commits, annotation look-ups go the other way, do
not have to have a tagname, and having tagname does not help our
look-up in any way. If we want to use tag to annotate various commits
by various people and keep them around, we would need global namespace
that would not cause them to crash (we can work this around by using
the object name of the tag, e.g. renaming 'for-linus' tag to $(git
rev-parse tags/for-linus), but that is merely a workaround of having to
name things that do not have to be named in the first place). As a
local storage machinery for annotations, tags hanging below refs/tags/
(or refs/audit for that matter) hierarchy with their own names is an
inappropriate model.
+ tags can auto-follow the commits when object transfer happens (at least
in the fetch direction), and for the purpose of "signed pull requests"
and "signed commits", this is a desirable property. When a repository
gains a commit, the annotations attached to the commit that are missing
from the receiving repository are automatically transferred from the
place the commit comes from. Annotations given to other commits that
are not transferred into the repository do not come to the repository.
- "git notes" is represented as a commit that records a tree that holds
the entire mapping from commit to its annotations, and the only way to
transferr it is to send it together with its history as a whole. It
does not have the nice auto-following property that transfers only the
relevant annotations.
+ "git notes" maps the commits to its annotations in the right direction;
the object name of an annotated object to its annotation.
In the longer term, I think we would need to extend the system in the
following way:
- Introduce a mapping machanism that can be locally used to map names of
the objects being annotated to names of other objects (most likely
blobs but there is nothing that fundamentally prevents you from
annotating a commit with a tree). The current "git notes" might be a
perfectly suitable representation of this, or it may turn out to be
lacking (I haven't thought things through), but the important point is
that this "mapping store" is _local_. fsck, repack and prune need to be
told that objects that store the annotation are reachable from the
annotated objects.
- Introduce a protocol extension to transfer this mapping information for
objects being transferred in an efficient way. When "rev-list --objects
have..want" tells us that the receiving end (in either fetch/push
direction) would have an object at the end of the primary transfer
(note that I did not say "an object will be sent in this transfer
transaction"; "have" does not come into the picture), we make sure that
missing annotations attached to the object is also transferred, and new
mapping is registered at the receiving end.
The detailed design for the latter needs more thought. The auto-following
of tags works even if nothing is being fetched in the primary transfer
(i.e. "git fetch" && "git fetch" back to back to update our origin/master
with the master at the origin) when a new tag is added to ancient part of
the history that leads to the master at the origin, but this is exactly
because the sending end advertises all the available tags and the objects
they point at so that we can tell what new tags added to an old object is
missing from the receiving end. This obviously would not scale well when
we have tens of thousands of objects to annotate. Perhaps an entry in the
"mapping store" would record:
- The object name of the object being annotated;
- The object name of the annotation;
- The "timestamp", i.e. when the association between the above two was
made--this can be local to the repository and a simple counter would
do.
and also maintain the last "timestamp" this repository sent annotations to
the remote (one timestamp per remote repository). When we push, we would
send annotations pertaining to the object reachable from what we are
pushing (not limited by what they already have, as the whole point of this
exercise is to allow us to transfer annotations added to an object long
after the object was created and sent to the remote) that is newer than
that "timestamp". Similarly, when fetching, we would send the "timestamp"
this repository last fetched annotations from the other end (which means
we would need one such "timestamp" per remote repository) and let the
remote side decide the set of new annotations they added since we last
synched that are on objects reachable from what we "want".
Or something like that.
[Footnote]
*1* By this word, I do not necessarily mean what the "git notes" command
manipulates. A tag that points at a commit is also equally a good vehicle
to annotate a commit after the fact.
*2* For this reason, it may make sense to "commit -S" such a merge
commit. The "mergetag" asserts the authenticity of the pull request from
the lieutenant whose history is being integrated, and the "gpgsig" asserts
the authenticity of the merge itself--the fact that it was made by the
integrator.
*3* I do not mean what "git commit -S" parked in 'pu' produces, which is
to store the signature in the commit. Adding "Signed-off-by:" after the
fact to an existing commit by many people is a more appropriate example.
^ permalink raw reply
* [RFC/PATCH] add update to branch support for "floating submodules"
From: Heiko Voigt @ 2011-11-09 17:40 UTC (permalink / raw)
To: git
This adds the capability to configure a branch which submodule update
will use to checkout the tips sha1 instead of the registered one.
It will first attempt to read the configuration directly from the
currently checked out .gitmodules file from the key
submodule.$name.branch. This configuration can be overridden by local
user configuration values. The parameter --branch can be used to
specify/override the branch using the commandline. The parameter
--checkout can be used to switch to the exact model for all submodules.
Such a thing is helpful if a user wants to follow a defined branches tip
in the submodule. Image such a branch is the stable branch for some
central library or similar.
When the newly checked out tip will not match the registered sha1 in the
superproject it will show up as a change as usual. You can imagine this
as a configuration which lets the upstream project tell a user the
branch it usually updates to. The usual revision control is still in
place.
---
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
Documentation/git-submodule.txt | 26 +++++++++--
git-submodule.sh | 47 ++++++++++++++++++++
t/t7406-submodule-update.sh | 93 +++++++++++++++++++++++++++++++++++++++
3 files changed, 162 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 6ec3fef..b8affa3 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -133,9 +133,11 @@ init::
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
- This will make the submodules HEAD be detached unless `--rebase` or
- `--merge` is specified or the key `submodule.$name.update` is set to
- `rebase`, `merge` or `none`.
+ This will make the submodules HEAD be detached. This will not
+ happen if `--rebase`, `--merge` or `--branch` are specified.
+ Also if the key `submodule.$name.update` is set to `rebase`,
+ `merge` or `none`. If `submodule.$name.branch` is set to some
+ local branch this will also not happen.
+
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
@@ -146,7 +148,16 @@ registered submodules, and update any nested submodules within.
+
If the configuration key `submodule.$name.update` is set to `none` the
submodule with name `$name` will not be updated by default. This can be
-overriden by adding `--checkout` to the command.
+overriden by adding `--checkout` to the command. `--checkout` can also
+be used to enforce exact checkout of submodule sha1's.
++
+If the configuration key `submodule.$name.branch` is set to some valid
+branch in the submodule named by `$name` the submodule will be updated
+to the tip of that branch instead of the registered sha1. This option
+can either be set in .gitmodules or via git's configuration. Gits local
+configuration takes precedence over .gitmodules. If you want to override
+the branch checkout you can use the value `HEAD` to tell git to checkout
+exactly the registered sha1.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -252,6 +263,13 @@ OPTIONS
If the key `submodule.$name.update` is set to `rebase`, this option is
implicit.
+--branch::
+ This option is only valid for the update command. You can use
+ this parameter to specify which branch you want to update all
+ submodules to. This is helpful if you want to update all
+ submodules to the tip of a certain branch or need to work on a
+ branch for all submodules for some time.
+
--init::
This option is only valid for the update command.
Initialize all submodules for which "git submodule init" has not been
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..a4b117b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -465,6 +465,14 @@ cmd_update()
--checkout)
update="checkout"
;;
+ --branch=*)
+ case "$1" in
+ *=*)
+ update="checkout"
+ branch=`expr "z$1" : 'z--[^=]*=\(.*\)'` ;;
+ *)
+ usage ;;
+ esac ;;
--)
shift
break
@@ -504,6 +512,45 @@ cmd_update()
update_module=$(git config submodule."$name".update)
fi
+ if ! test -z "$branch"
+ then
+ branch_module=$branch
+ else
+ if test "$update" != "checkout"
+ then
+ branch_module=$(git config submodule."$name".branch)
+ if test -z "$branch_module"
+ then
+ branch_module=$(git config -f .gitmodules --get submodule."$name".branch)
+ fi
+ fi
+ fi
+
+ if test "$branch_module" = "HEAD"
+ then
+ branch_module=
+ fi
+
+ if ! test -z "$branch_module"
+ then
+ (clear_local_git_env; cd "$path" &&
+ if test ! $nofetch
+ then
+ git-fetch --all >/dev/null 2>/dev/null || exit 1
+ fi) ||
+ die "$(eval_gettext "Unable to fetch submodule in path '\$path'")"
+
+ sha1=$(clear_local_git_env; cd "$path" &&
+ git rev-parse $branch_module) ||
+ say "$(eval_gettext "Unable to find branch '\$branch_module' in submodule path '\$path'")"
+ fi
+
+ if test "$branch" -a "$update" != "checkout"
+ then
+ die "$(eval_gettext "You can not set update='\$update' and
+use a branch for submodule '\$path'")"
+ fi
+
if test "$update_module" = "none"
then
echo "Skipping submodule '$path'"
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 33b292b..517ed83 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -611,4 +611,97 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
)
'
+test_expect_success '--branch updates follow the given branch' '
+ git clone . branch &&
+ (cd branch &&
+ git submodule add ./submodule submodule1 &&
+ git submodule add ./submodule submodule2 &&
+ (cd submodule1 &&
+ git rev-parse HEAD >../expected1 &&
+ git checkout HEAD^) &&
+ (cd submodule2 &&
+ git rev-parse HEAD >../expected2 &&
+ git checkout HEAD^) &&
+ git add submodule1 &&
+ git add submodule2 &&
+ git commit -m "add submodule1 and submodule2" &&
+ git submodule update --branch=origin/master &&
+ (cd submodule1 && git rev-parse HEAD >../actual1) &&
+ (cd submodule2 && git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2
+ )
+'
+
+cat >branch/expect_status <<EOF
+ M submodule1
+EOF
+
+check_submodule_one_follows()
+{
+ (cd submodule1 &&
+ git rev-parse origin/master >../expected1 &&
+ git rev-parse HEAD >../actual1) &&
+ (cd submodule2 &&
+ git rev-parse origin/master^ >../expected2 &&
+ git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2 &&
+ git status --porcelain --untracked-files=no >actual_status &&
+ test_cmp expect_status actual_status
+}
+
+check_both_submodules_exact()
+{
+ (cd submodule1 &&
+ git rev-parse origin/master^ >../expected1 &&
+ git rev-parse HEAD >../actual1) &&
+ (cd submodule2 &&
+ git rev-parse origin/master^ >../expected2 &&
+ git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2 &&
+ test -z "$(git status --porcelain --untracked-files=no)"
+}
+
+test_expect_success 'local branch configuration follows branch' '
+ (cd branch &&
+ git submodule update &&
+ check_both_submodules_exact &&
+ git config submodule.submodule1.branch origin/master &&
+ git submodule update &&
+ check_submodule_one_follows
+ )
+'
+
+test_expect_success '.gitmodules branch configuration follows branch' '
+ (cd branch &&
+ git config --unset submodule.submodule1.branch &&
+ git submodule update &&
+ check_both_submodules_exact &&
+ git config -f .gitmodules submodule.submodule1.branch origin/master &&
+ git add .gitmodules &&
+ git commit -m ".gitmodules follows branch" &&
+ git submodule update &&
+ check_submodule_one_follows
+ )
+'
+
+test_expect_success '--checkout commandline overrides branch config' '
+ (cd branch &&
+ git submodule update --checkout &&
+ check_both_submodules_exact
+ )
+'
+
+test_expect_success 'local config overrides .gitmodules branch config' '
+ (cd branch &&
+ git submodule update &&
+ check_submodule_one_follows &&
+ git config submodule.submodule1.branch HEAD &&
+ git submodule update &&
+ check_both_submodules_exact
+ )
+'
+
test_done
--
1.7.7.433.gcf1e7
^ permalink raw reply related
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Junio C Hamano @ 2011-11-09 18:01 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20111109174027.GA28825@book.fritz.box>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> This is almost ready but I would like to know what users of the
> "floating submodule" think about this.
Thanks for working on this.
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody, but it is merely an inertia of people who (perhaps mistakenly)
thought svn externals that are not anchored to a particular revision is a
feature when it is just a limitation in reality. During the GitTogether'11
we learned that Android that uses floating model does not really have to.
^ permalink raw reply
* Re: [PATCH] Add abbreviated commit hash to rebase conflict message
From: Junio C Hamano @ 2011-11-09 18:25 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Ævar Arnfjörð, Jonas Flodén, Eric Herman,
Fernando Vezzosi, Git List
In-Reply-To: <7v4nyg6b9s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
>> On Sun, Nov 6, 2011 at 21:27, Junio C Hamano <gitster@pobox.com> wrote:
>>> In what situation does it make sense to say "It came from _this_ commit"?
>>>
>>> I think there is a separate variable that allows any part of the script if
>>> we are being run as a backend of rebase or not, and that is the condition
>>> you are looking for.
>>
>> The closest I could find is:
>>
>> if test -f "$dotest/rebasing"
>>
>> Which is exactly the case when commit is set. Do you prefer the "-f
>> $dotest/rebasing" test or the "-n $commit" one?
>
> Given the variable scoping rules of vanilla shell script, relying on the
> variable $commit is a very bad idea to begin with. I think the variable
> also is used to hold the final commit object name produced by patch
> application elsewhere in the script in the same loop, and I do not think
> existing code clears it before each iteration, as each part of the exiting
> code uses the variable only immediately after that part assigns to the
> variable for its own purpose, and they all know that nobody uses the
> variable as a way for long haul communication media between different
> parts of the script. Unless your patch updated that aspect of the
> lifetime rule for the variable, which I doubt you did, using $commit would
> introduce yet another bug without solving anything, I would think.
I was looking at git-am today for a separate topic. Doesn't it appear to
you that $dotest/original-commit is what serves your purpose the best?
The file is removed before starting to process a new input (i.e. message
in the mbox), created only after we read the from line and determine it is
really the commit we are rebasing, and is left intact until we decide the
patch was applied correctly and write the result out as a tree.
It might be a clean-up to get rid of $dotest/original-commit file, rename
the variable to $original_commit and initialize it to an empty string
where we currently have 'rm -f "$dotest/original-commit"' (and replace the
check 'test -f "$dotest/original-commit"' later in the script with a check
'test -n "$original_commit"'), though.
^ permalink raw reply
* [PATCH 0/3] commit-tree updates
From: Junio C Hamano @ 2011-11-09 21:01 UTC (permalink / raw)
To: git
Here are a handful of patches to the lowest level plumbing commit-tree to
teach it to record extended headers. With this series, scripted Porcelain
like rebase--am can propagate the "mergetag" header while rebasing.
Junio C Hamano (3):
commit-tree: update the command line parsing
commit-tree: teach -m/-F options to read logs from elsewhere
commit-tree: teach -x <extra>
Documentation/git-commit-tree.txt | 17 ++++++-
builtin/commit-tree.c | 92 ++++++++++++++++++++++++++++++-------
2 files changed, 89 insertions(+), 20 deletions(-)
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply
* [PATCH 1/3] commit-tree: update the command line parsing
From: Junio C Hamano @ 2011-11-09 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320872495-7545-1-git-send-email-gitster@pobox.com>
We have kept the original "git commit-tree <tree> -p <parent> ..." syntax
forever, but "git commit-tree -p <parent> -p <parent> ... <tree>" would be
more intuitive way to spell it. Dashed flags along with their arguments
come first and then the "thing" argument after the flags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/commit-tree.c | 31 ++++++++++++++++++-------------
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
index d083795..92cfbaf 100644
--- a/builtin/commit-tree.c
+++ b/builtin/commit-tree.c
@@ -27,7 +27,7 @@ static void new_parent(struct commit *parent, struct commit_list **parents_p)
int cmd_commit_tree(int argc, const char **argv, const char *prefix)
{
- int i;
+ int i, got_tree = 0;
struct commit_list *parents = NULL;
unsigned char tree_sha1[20];
unsigned char commit_sha1[20];
@@ -37,20 +37,25 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
if (argc < 2 || !strcmp(argv[1], "-h"))
usage(commit_tree_usage);
- if (get_sha1(argv[1], tree_sha1))
- die("Not a valid object name %s", argv[1]);
- for (i = 2; i < argc; i += 2) {
- unsigned char sha1[20];
- const char *a, *b;
- a = argv[i]; b = argv[i+1];
- if (!b || strcmp(a, "-p"))
- usage(commit_tree_usage);
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "-p")) {
+ unsigned char sha1[20];
+ if (argc <= ++i)
+ usage(commit_tree_usage);
+ if (get_sha1(argv[i], sha1))
+ die("Not a valid object name %s", argv[i]);
+ assert_sha1_type(sha1, OBJ_COMMIT);
+ new_parent(lookup_commit(sha1), &parents);
+ continue;
+ }
- if (get_sha1(b, sha1))
- die("Not a valid object name %s", b);
- assert_sha1_type(sha1, OBJ_COMMIT);
- new_parent(lookup_commit(sha1), &parents);
+ if (get_sha1(arg, tree_sha1))
+ die("Not a valid object name %s", arg);
+ if (got_tree)
+ die("Cannot give more than one trees");
+ got_tree = 1;
}
if (strbuf_read(&buffer, 0, 0) < 0)
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply related
* [PATCH 3/3] commit-tree: teach -x <extra>
From: Junio C Hamano @ 2011-11-09 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320872495-7545-1-git-send-email-gitster@pobox.com>
By feeding the header part of the original commit with this parameter,
e.g. -x "$(git cat-file commit $commit | sed -n -e /^$/q -e p)", extra
headers of another commit can be transplanted to the resulting commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-commit-tree.txt | 3 ++-
builtin/commit-tree.c | 20 ++++++++++++++++++--
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index cfb9906..060e79d 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git commit-tree' <tree> [(-p <parent>)...] < changelog
-'git commit-tree' [(-p <parent>)...] [(-m <message>)...] [(-F <file>)...] <tree>
+'git commit-tree' [(-p <parent>)...] [(-m <message>)...] [(-F <file>)...]
+ [(-x <extra>)...]<tree>
DESCRIPTION
-----------
diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
index db5b6e5..8b0a223 100644
--- a/builtin/commit-tree.c
+++ b/builtin/commit-tree.c
@@ -9,7 +9,7 @@
#include "builtin.h"
#include "utf8.h"
-static const char commit_tree_usage[] = "git commit-tree [(-p <sha1>)...] [-m <message>] <sha1> < changelog";
+static const char commit_tree_usage[] = "git commit-tree [(-p <sha1>)...] [-m <message>] [-x <extra>] <sha1> < changelog";
static void new_parent(struct commit *parent, struct commit_list **parents_p)
{
@@ -32,6 +32,7 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
unsigned char tree_sha1[20];
unsigned char commit_sha1[20];
struct strbuf buffer = STRBUF_INIT;
+ struct commit_extra_header *extra = NULL, **extra_tail = &extra;
git_config(git_default_config, NULL);
@@ -86,6 +87,20 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
continue;
}
+ if (!strcmp(arg, "-x")) {
+ struct commit_extra_header *x;
+ if (argc <= ++i)
+ usage(commit_tree_usage);
+ x = read_commit_extra_header_lines(argv[i], strlen(argv[i]));
+ if (x) {
+ *extra_tail = x;
+ while (x->next)
+ x = x->next;
+ extra_tail = &x->next;
+ }
+ continue;
+ }
+
if (get_sha1(arg, tree_sha1))
die("Not a valid object name %s", arg);
if (got_tree)
@@ -98,7 +113,8 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
die_errno("git commit-tree: failed to read");
}
- if (commit_tree(buffer.buf, tree_sha1, parents, commit_sha1, NULL)) {
+ if (commit_tree_extended(buffer.buf, tree_sha1, parents, commit_sha1,
+ NULL, extra)) {
strbuf_release(&buffer);
return 1;
}
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply related
* [PATCH 2/3] commit-tree: teach -m/-F options to read logs from elsewhere
From: Junio C Hamano @ 2011-11-09 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320872495-7545-1-git-send-email-gitster@pobox.com>
Just like "git commit" does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-commit-tree.txt | 16 +++++++++++--
builtin/commit-tree.c | 43 ++++++++++++++++++++++++++++++++++--
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index 02133d5..cfb9906 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -9,7 +9,8 @@ git-commit-tree - Create a new commit object
SYNOPSIS
--------
[verse]
-'git commit-tree' <tree> [(-p <parent commit>)...] < changelog
+'git commit-tree' <tree> [(-p <parent>)...] < changelog
+'git commit-tree' [(-p <parent>)...] [(-m <message>)...] [(-F <file>)...] <tree>
DESCRIPTION
-----------
@@ -17,7 +18,8 @@ This is usually not what an end user wants to run directly. See
linkgit:git-commit[1] instead.
Creates a new commit object based on the provided tree object and
-emits the new commit object id on stdout.
+emits the new commit object id on stdout. The log message is read
+from the standard input, unless `-m` or `-F` options are given.
A commit object may have any number of parents. With exactly one
parent, it is an ordinary commit. Having more than one parent makes
@@ -39,9 +41,17 @@ OPTIONS
<tree>::
An existing tree object
--p <parent commit>::
+-p <parent>::
Each '-p' indicates the id of a parent commit object.
+-m <message>::
+ A paragraph in the commig log message. This can be given more than
+ once and each <message> becomes its own paragraph.
+
+-F <file>::
+ Read the commit log message from the given file. Use `-` to read
+ from the standard input.
+
Commit Information
------------------
diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
index 92cfbaf..db5b6e5 100644
--- a/builtin/commit-tree.c
+++ b/builtin/commit-tree.c
@@ -9,7 +9,7 @@
#include "builtin.h"
#include "utf8.h"
-static const char commit_tree_usage[] = "git commit-tree <sha1> [(-p <sha1>)...] < changelog";
+static const char commit_tree_usage[] = "git commit-tree [(-p <sha1>)...] [-m <message>] <sha1> < changelog";
static void new_parent(struct commit *parent, struct commit_list **parents_p)
{
@@ -51,6 +51,41 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
continue;
}
+ if (!strcmp(arg, "-m")) {
+ if (argc <= ++i)
+ usage(commit_tree_usage);
+ if (buffer.len)
+ strbuf_addch(&buffer, '\n');
+ strbuf_addstr(&buffer, argv[i]);
+ strbuf_complete_line(&buffer);
+ continue;
+ }
+
+ if (!strcmp(arg, "-F")) {
+ int fd;
+
+ if (argc <= ++i)
+ usage(commit_tree_usage);
+ if (buffer.len)
+ strbuf_addch(&buffer, '\n');
+ if (!strcmp(argv[i], "-"))
+ fd = 0;
+ else {
+ fd = open(argv[i], O_RDONLY);
+ if (fd < 0)
+ die_errno("git commit-tree: failed to open '%s'",
+ argv[i]);
+ }
+ if (strbuf_read(&buffer, fd, 0) < 0)
+ die_errno("git commit-tree: failed to read '%s'",
+ argv[i]);
+ if (fd && close(fd))
+ die_errno("git commit-tree: failed to close '%s'",
+ argv[i]);
+ strbuf_complete_line(&buffer);
+ continue;
+ }
+
if (get_sha1(arg, tree_sha1))
die("Not a valid object name %s", arg);
if (got_tree)
@@ -58,8 +93,10 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
got_tree = 1;
}
- if (strbuf_read(&buffer, 0, 0) < 0)
- die_errno("git commit-tree: failed to read");
+ if (!buffer.len) {
+ if (strbuf_read(&buffer, 0, 0) < 0)
+ die_errno("git commit-tree: failed to read");
+ }
if (commit_tree(buffer.buf, tree_sha1, parents, commit_sha1, NULL)) {
strbuf_release(&buffer);
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply related
* Re: RFH: unexpected reflog behavior with --since=
From: Jeff King @ 2011-11-09 22:01 UTC (permalink / raw)
To: Eric Raible; +Cc: git@vger.kernel.org
In-Reply-To: <4EB9C7D1.30201@nextest.com>
On Tue, Nov 08, 2011 at 04:22:41PM -0800, Eric Raible wrote:
> # It's reported correctly here:
> git log -g --oneline --since=$add_b
>
> # But after a reset no history isn't shown.
> git reset --hard HEAD^
> git log -g --oneline --since=$add_b
>
> Is this a bug? Of course everything is reported when --since isn't used,
> but not so when limited with --since.
It's sort of a bug. And sort of a missing feature.
In the normal revision walking case, git walks the history graph
backwards, hitting the parent of each commit (and when there are
multiple lines of history, we traverse them in commit timestamp order).
So "--since" works not just by omitting non-matching commits from the
output, but also by stopping the traversal when we go too far back in
time. In a sense, this is purely an optimization, as it shouldn't change
the output. But it's an important one, because it makes looking back in
time O(how far back) instead of O(size of all history).
This optimization breaks down badly, of course, in the face of clock
skew (i.e., a commit whose timestamp is further back than its parent).
There are a few tricks we do to avoid small runs of moderate skew, and
in practice it works well.
Now let's look at reflog walking. It's kind of bolted on to the side
of the revision traversal machinery. We walk through the reflog
backwards and pretend that entry N's parent is entry N-1 (you can see
this if you do "git log -g -p", for example; you see the patch versus
the last reflog entry, not the patch against the commit's true parent).
In the case of rewound history (like the reset you showed above), this
means that the history graph will appear to have bad clock skew. The
timestamp of HEAD@{0} is going to be much earlier than its pretend
parent, HEAD@{1}. And the "--since" optimization is going to cut off
traversal, even though there are more interesting commits to be shown.
So in that sense, I think it's a bug, and we should probably disable the
exit-early-from-traversal optimization when we're walking reflogs.
But it may also be a misfeature, because it's not clear what you're
actually trying to limit by. We have commit timestamps, of course, but
when we are walking reflogs, we also have reflog timestamps. Did you
actually want to say "show me all commits in the reflog, in reverse
reflog order, omitting commits that happened before time t"? Or did you
really mean "show me the reflog entries that happened before time t,
regardless of their commit timestamp"?
In the latter case, we would either need a new specifier (like
"--reflog-since"), or to rewrite the commit timestamp when we rewrite
the parent pointers.
The latter has a certain elegance to it (we are making a pretend linear
history graph out of the reflog, so faking the timestamps to be sensible
and in order is a logical thing to do) but I worry about lying too much
in the output. Something like "git log -g --format=%cd" would now have
the fake timestamp in the output. But then, we already show the fake
parents in the output, so I don't know that this is any worse.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox