* [PATCH] Wrap completions in `type git' conditional statement.
From: Sung Pae @ 2009-11-12 9:56 UTC (permalink / raw)
To: spearce; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Hello,
I don't know if this has come up before (I didn't notice in a casual grep of git log), but attached is a little patch to wrap the bash completion script in a `type git' check.
From the patch header:
--
The onus for checking if a command exists before loading its completions
properly falls on individual completion files since they are normally
sourced from a completions directory (e.g. source /etc/bash_completion.d/*),
or perhaps from a single file concatenated from other completion files.
Also, this is standard practice with other bash-completion scripts.
--
Cheers,
Sung Pae
[-- Attachment #2: 0001-completion-Wrap-completions-in-type-git-conditional-.patch --]
[-- Type: application/octet-stream, Size: 2323 bytes --]
From 5e9d29fa1938554903631a4b560e08211b8efab3 Mon Sep 17 00:00:00 2001
From: Sung Pae <sung@metablu.com>
Date: Thu, 12 Nov 2009 02:55:28 -0600
Subject: [PATCH] completion: Wrap completions in `type git' conditional statement
The onus for checking if a command exists before loading its completions
properly falls on the individual completion files since they are normally
sourced from a completions directory (e.g. source /etc/bash_completion.d/*), or
perhaps from a single file concatenated from other completion files.
Also, this is standard practice with other bash-completion scripts.
---
contrib/completion/git-completion.bash | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..f1f9fb8 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -18,16 +18,13 @@
# To use these routines:
#
# 1) Copy this file to somewhere (e.g. ~/.git-completion.sh).
-# 2) Added the following line to your .bashrc:
+# 2) Add the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
+# Note that git must be available in your PATH or as an alias at the
+# time of sourcing.
#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -60,6 +57,8 @@
# git@vger.kernel.org
#
+{ type git || type git.exe; } &>/dev/null && {
+
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -2242,3 +2241,5 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
|| complete -o default -o nospace -F _git git.exe
fi
+
+} # type git
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Jeff King @ 2009-11-12 9:56 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Sam Vilain, paulus, git
In-Reply-To: <20091112093611.GA47285@gmail.com>
On Thu, Nov 12, 2009 at 01:36:13AM -0800, David Aguilar wrote:
> When I have more time I can switch gitk over to git-difftool
> which I know is /tmp safe. I only dabble in tcl but the
> docs say that mkdir does not error out when given
> directories that already exist. It does error out when
> given a file.
OK, then I think we would be vulnerable, as I can make a .gitk-tmp.$PID
directory owned by me that your gitk will happily use.
> The /tmp trick would require them knowing the SHA-1 that
> we're diffing and symlinking the names to paths they want
> us to destroy. It seems paranoid to worry about it ;)
But the SHA-1 is not hard to guess[1], as you have a finite,
easily-enumerable list of them in your repository. :) One thing that
does make it harder is that gitk actually checks to see if a file is
already there before creating it (presumably not for security, but for
efficiency). Which means I can't just pre-seed a trap and wait for you
to run gitk; I have to actually race you and create the file between
your "file exists" check and the eventual "git show $filename >$output"
which will hose it.
Probably I can win that race given a sufficient number of attempts, but
attempts are made at a human pace. So in practice it's probably pretty
hard to exploit. Still, I'd rather see it done properly on principle.
Then we _know_ we're not missing some trick, and there's no chance of a
later code change increasing an attacker's probability of success.
-Peff
[1] I was also going to suggest a social-engineering attack, like "hey,
I screwed up my repository. Can you take a look?" Then you don't need to
guess the SHA-1, as you convince the victim to look at a specific one.
But that attack is already much, much worse: we respect items in
.git/config regardless of whether it is owned by the running user. So it
is not actually safe to "cd ~other_user/project && git diff".
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Björn Steinbrink @ 2009-11-12 9:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Nicolas Sebrecht, Baz, Peter Krefting,
Git Mailing List, Johannes Schindelin
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>
On 2009.11.11 23:55:09 -0800, Junio C Hamano wrote:
> 58634db (rebase: Allow merge strategies to be used when rebasing,
> 2006-06-21) added "-m" and "-s" to rebase to solve the problem of rebasing
> against an upstream that has moved files. What the commit actually did
> was to use recursive (by default) while giving longer rope to the users by
> choosing other strategies with "-s", without making any judgement as to
> why other strategies may possibly be useful.
At least the original reason for 58634db became (partially?) moot half a
year later, thanks to 579c9bb19 "Use merge-recursive in git-am -3".
Rebase already falls back to recursive merging in am, so using rebase -m
with the recursive strategy just stops it from trying the fast path,
right?
That should probably be reflected in the man page, but honestly I have
no idea what to write there now. The note about recursive should go, but
keeping only "Use merging strategies to rebase" doesn't actually look
like it's going to be helpful in any way.
> Perhaps there is some different issue at the root of this one. Why would
> anybody be tempted to say "-s ours" while running a rebase? What did the
> user want to see it do (instead of being a no-op because "ours" by
> definition ignores the tree the change is replayed from)?
Given the few requests I've seen of it (here + #git), I'd guess that
the user wants "git rebase -s ours $up" to do either:
MB=$(git merge-base $up HEAD)
git filter-branch --parent-filter "sed -e s/$MB/$up/" -- HEAD --not $up
i.e. just re-attach things to upstream, ignoring whatever upstream did
(git-svn users seem to want something like that sometimes to be able to
dcommit. Dunno if they have some hatred against the other users of their
svn repo ;-))
Or the user wants the infamous "resolve conflicts to want I did", often
enough without thinking about what that actually means and how it can
easily lead to total crap. (Yes, I'm biased...)
Björn
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-12 9:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Nicolas Sebrecht, Baz, Git Mailing List,
Johannes Schindelin, Björn Steinbrink
In-Reply-To: <7vvdhggote.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Perhaps there is some different issue at the root of this one. Why would
> anybody be tempted to say "-s ours" while running a rebase? What did the
> user want to see it do (instead of being a no-op because "ours" by
> definition ignores the tree the change is replayed from)?
The reason why I wanted it in my initial example was due to me misreading
the documentation of "ours".
My scenario is like this:
I have my web site under Git control (used to be CVS). Some parts of the web
site is updated in-place (blog comments being saved as HTML directly in the
web tree), whereas all other edits are done in clones of the repsository.
These changes are then added and committed to the checked out web tree and
pushed to the central repo.
In some cases, I wish to edit the comments in one of my clones (to remove
spam not stopped by my spam filters, for instance), but editing these risks
creating a conflict if there has been other changes in the mean time.
The web tree checkout script uses rebase to avoid introducing merge commits
every time the blog comment is updated, as it in 99 % of cases is unrelated
to any other changes found in the central repo.
In the few cases where the blog comment update from the web tree conflicts
with a change in the central repo, I want the "git pull --rebase" call to
overwrite any changes in the central repo with my changes in the web tree
(meaning that I would later have to manually re-delete the spam comments,
but I can live with that).
> It is easy to dismiss it as a user misconception and it also is tempting
> to think that it would be helped with updated description of "ours" to
> dispel that misconception, but there may be some user wish that is totally
> different from "ours merge" strategy but still can be validly labelled
> using a word "ours" by somebody who does not know the way the word "ours"
> is used in the git land, and satisfying that unknown user wish might be
> the real solution to this issue.
Yes, I am apparently looking for something that is not available in the Git
codebase yet. :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] gitk: Honor TMPDIR when viewing diffs externally
From: David Aguilar @ 2009-11-12 9:37 UTC (permalink / raw)
To: paulus; +Cc: peff, sam, git, David Aguilar
gitk's external diff fails when browsing read-only repositories.
This is due to gitk's assumption that the current directory is
always writable. By honoring TMPDIR we avoid this problem and
allow users to define the location used for temporary files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
gitk | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..a065e94 100755
--- a/gitk
+++ b/gitk
@@ -3170,11 +3170,15 @@ proc flist_hl {only} {
}
proc gitknewtmpdir {} {
- global diffnum gitktmpdir gitdir
+ global diffnum gitktmpdir gitdir env
if {![info exists gitktmpdir]} {
- set gitktmpdir [file join [file dirname $gitdir] \
- [format ".gitk-tmp.%s" [pid]]]
+ if {[info exists env(TMPDIR)]} {
+ set tmpdir $env(TMPDIR)
+ } else {
+ set tmpdir [file dirname $gitdir]
+ }
+ set gitktmpdir [file join $tmpdir [format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-12 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sam Vilain, paulus, git
In-Reply-To: <20091112083559.GB17552@coredump.intra.peff.net>
On Thu, Nov 12, 2009 at 03:35:59AM -0500, Jeff King wrote:
> On Wed, Nov 11, 2009 at 08:44:53AM -0800, David Aguilar wrote:
>
> > gitk writes file@commit and file@commit^ to temporary files
> > and diffs them using an external diff tool.
> >
> > Shall I reroll with s/GITK_TMPDIR/TMPDIR/ ?
>
> gitk seems to use a very predictable temp filename (".gitk-tmp.$PID").
> Have you checked that you are not introducing any security holes by
> creating that predictable filename in a publicly writable tmpdir?
>
> It looks like it always tries to "mkdir" the file. Does tcl's mkdir
> function barf on an existing directory? If so, then I think we may be
> safe from the naive:
>
> tmp=.gitk-tmp.`pidof_other_users_gitk`
> mkdir $tmp
> ln -s /file/for/other/user/to/destroy /tmp/1
>
> attack. And I think we are not susceptible to races because we fail if
> the mkdir fails (instead of doing something stupid like stat followed
> by mkdir).
>
> But it has been a long time since I thought about /tmp security, so I
> may be forgetting something.
>
> -Peff
Thanks for the review.
I'm about to reroll with a new subject, "gitk: Honor TMPDIR..."
When I have more time I can switch gitk over to git-difftool
which I know is /tmp safe. I only dabble in tcl but the
docs say that mkdir does not error out when given
directories that already exist. It does error out when
given a file.
The /tmp trick would require them knowing the SHA-1 that
we're diffing and symlinking the names to paths they want
us to destroy. It seems paranoid to worry about it ;)
but since if it's a real concern than I'll try to
get to the git-difftool rework within the next two week.
I only dabble in tcl ;)
--
David
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-12 9:35 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <a2633edd0911120103y688a2b2ah2c33c47de195ee81@mail.gmail.com>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
> > Will review the procedure for filtering branches :(
>
> A quick review does not show something obviously wrong on my side.
>
> The commit on the rewritten repo has a different sha-1 which is
> expected. So to me it seems that after a filter-branch on a git-svn
> repo it is mandatory to recreate all .rev_map*? Is that right? Is so,
> this is the missing piece in the procedure on my side.
Yes, you need to recreate all the .rev_map* files if you use
filter-branch. Just remove them and they should be automatically
recreated for your case (not using --no-metadata or --use-svm-props)
--
Eric Wong
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Nicolas Sebrecht @ 2009-11-12 9:31 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Daniele Segato, Git Mailing List
In-Reply-To: <9accb4400911120129h54609846jac9eb3b6cb07b792@mail.gmail.com>
The 12/11/09, Daniele Segato wrote:
> On Wed, Nov 11, 2009 at 8:24 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> > The 11/11/09, Daniele Segato wrote:
> >
> > If you want to track changes of settings in a per-production-repo basis,
> > you should do it _out_ of your main development repository. The latter
> > should have a publishable template instead (eg. "user = user_login",
> > "password = set_your_password").
>
> you are probably right but even if I place this files outside my
> repository I still have to modify them manually..
I don't understand. You'll still have to manually these files regardless
_how_ they are tracked.
> it's the same of having them into the repo but in .gitignore
When I say, "out of the main development repository", I don't think "out
of the directory of the repository" but "out of the tracking git system".
I think you should look at 'git subtree' or 'git submodule' to track the
setting files out of the _main_ repository and _inside_ the main
development directory.
> we are customizing a third party product and I can't change the way it
> is build up.
>
> I don't think that this situation is so uncommon anyway.
Yeah, it doesn't help to be unable to do everything we want! But I'm
pretty sure git can do something very convenient in your case.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Daniele Segato @ 2009-11-12 9:29 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Git Mailing List
In-Reply-To: <20091111192449.GH27518@vidovic>
On Wed, Nov 11, 2009 at 8:24 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> This looks to _not_ be a piece of the development project. Settings used
> for the tests suites, company where you work, etc _are_ clones (from the
> abstract POV, at least) of the maintainer public repository.
>
> If you want to track changes of settings in a per-production-repo basis,
> you should do it _out_ of your main development repository. The latter
> should have a publishable template instead (eg. "user = user_login",
> "password = set_your_password").
you are probably right but even if I place this files outside my
repository I still have to modify them manually..
it's the same of having them into the repo but in .gitignore
we are customizing a third party product and I can't change the way it
is build up.
I don't think that this situation is so uncommon anyway.
Regards,
Daniele
^ permalink raw reply
* Re: [PATCHv3/RFC 4/5] gitweb: Create links leading to 'blame_incremental' using JavaScript
From: Jakub Narebski @ 2009-11-12 9:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, git, Fredrik Kuivinen, Giuseppe Bilotta,
Luben Tuikov, Martin Koegler
In-Reply-To: <7vtyx0f9rd.fsf@alter.siamese.dyndns.org>
On Thu, 12 Nov 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > But even if incremental blame turns out to be slower than incremental
> > blame it still has the advantage of being _incremental_. You have at
> > least some result soon.
>
> It wasn't it was slow that bothered me, but early implementations of
> incremental blame I tried didn't _appear_ as incremental. That was the
> dissapointing part.
>
> At the protocol and implementation level it certainly was feeding data
> incrementally to the browser, but the end user experience on the screen
> was "click....wait...wait...wait...voila the whole blame appears", not
> "click...trickle...trickle...trickle...ah everything is filled". The
> latter obviously is what an incremental one should be aiming for.
>
> No I haven't tried your latest code. Probably I should.
The problem with earliest versions of incremental blame _in some browsers_
was that 'onreadystatechange' event was not fired as soon as new part of
blame data was available (truth to be said the definition of this event
is a bit underspecified). That is why newer versions of interactive blame
use timer (alarm) to check every 1 second if there is something new.
Perhaps interactive blame should use 'onprogress' event instead, which is
well defined... but is in _draft_ of standard (XHR 2.0), and not yet in
established standard.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-12 9:03 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <a2633edd0911120011u34d69100p1565ab5bf96a7709@mail.gmail.com>
Eric,
> Will review the procedure for filtering branches :(
A quick review does not show something obviously wrong on my side.
The commit on the rewritten repo has a different sha-1 which is
expected. So to me it seems that after a filter-branch on a git-svn
repo it is mandatory to recreate all .rev_map*? Is that right? Is so,
this is the missing piece in the procedure on my side.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Jeff King @ 2009-11-12 8:35 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Sam Vilain, paulus, git
In-Reply-To: <20091111164451.GA45475@gmail.com>
On Wed, Nov 11, 2009 at 08:44:53AM -0800, David Aguilar wrote:
> gitk writes file@commit and file@commit^ to temporary files
> and diffs them using an external diff tool.
>
> Shall I reroll with s/GITK_TMPDIR/TMPDIR/ ?
gitk seems to use a very predictable temp filename (".gitk-tmp.$PID").
Have you checked that you are not introducing any security holes by
creating that predictable filename in a publicly writable tmpdir?
It looks like it always tries to "mkdir" the file. Does tcl's mkdir
function barf on an existing directory? If so, then I think we may be
safe from the naive:
tmp=.gitk-tmp.`pidof_other_users_gitk`
mkdir $tmp
ln -s /file/for/other/user/to/destroy /tmp/1
attack. And I think we are not susceptible to races because we fail if
the mkdir fails (instead of doing something stupid like stat followed
by mkdir).
But it has been a long time since I thought about /tmp security, so I
may be forgetting something.
-Peff
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Thomas Rast @ 2009-11-12 8:27 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm>
Here's my promised review of the whole patch. Much of the text fits
my understanding of what's actually going on, but Junio will have the
final word on what he actually does (or what a sensible simplification
might be).
rocketraman@fastmail.fm wrote:
> +The current maintenance branch is optionally copied to another branch
> +named with the older release version number (e.g. maint-X.Y.(Z-1)
> +where X.Y.Z is the previous release). This allows for further
> +maintenance releases on the older codebase.
The use of Z-1 confused me; I guess by "previous release" you mean
"the release we just tagged in the last step". Otherwise the maint
version number would come out wrong.
> +.Update maint to new release
> +[caption="Recipe: "]
> +=====================================
> +* `git checkout maint`
> +* `git merge master`
> +=====================================
> +
> +This updates 'maint' from 'master', while preserving the 'maint'
> +reflog.
I agree with what Junio said in the other mail: it's important at this
point that this was a fast-forward. (If it's not, master could be
missing some fixes made on maint.)
> +An alternative approach to updating the 'maint' branch is to run
> +
> + $ git branch -f maint master
In my book the alternative approach is
git branch -m maint maint-X.Y.(Z-1)
git branch maint master
I'd rather not teach users to play with loaded guns, much less in a
"good examples of workflows" manpage.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Thomas Rast @ 2009-11-12 8:10 UTC (permalink / raw)
To: Raman Gupta; +Cc: Junio C Hamano, git
In-Reply-To: <4AFB57A3.2020002@fastmail.fm>
Raman Gupta wrote:
> Junio C Hamano wrote:
> > Please set the tone straight. If this is to suggest various possible
> > workflows in general vague terms, "may use" would be good. If this is to
> > precisely describe what I do, then there won't be "you could do this, or
> > you could do that." Your "may use" suggests the former, but the commit
> > log message claims the latter. Which document are you writing?
>
> Ok. The current document is inconsistent. In places it uses "the
> maintainer" and in other places it uses "you". In any case, it seems
> that the "maintainer" here is not "Junio Hamano" -- rather, it is the
> reader.
>
> Let me create a separate (and first) cleanup patch to fix the existing
> inconsistencies in this man page. I would prefer to use the pronoun
> "you" consistently as also suggested by Thomas Rast.
Well, I'm not sure if this is also in reply to my comment
} The current gitworkflows is mostly formulated in the imperative, [...]
} or by directly describing the tools in the third person, [...]
but note that I do not consider the current form to be inconsistent
(though you may of course convince me otherwise). It addresses the
presumed user with "you", which is not always the maintainer. For
example, when talking about patch submission we have
If the maintainer tells you that your patch no longer applies to the
current upstream, you will have to rebase your topic (you cannot use a
merge because you cannot format-patch merges):
since the presumed user of a patch-submission workflow is a
contributor, not the maintainer. Indeed much of the text talks
*about* the workflow used by our esteemed maintainer, but is addressed
to a contributor who wants to understand how it works so he can
participate.
IOW, I'm neither a native speaker nor a professional writer, so you
may of course convince me that there is something to fix. I am,
however, fairly sure that s/maintainer/you/ and then fixing the
grammar is *not* a good thing.
[BTW, it would have been nice to get a Cc to begin with, since the
entire manpage blames to me. I noticed the thread anyway, but other
times I do not have the time to scan the entire list.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-12 8:11 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <20091112071121.GA569@dcvr.yhbt.net>
Eric,
> Oh... Any chance that lost commit you couldn't find was clobbered
> by filter-branch? That would explain a lot...
I still have the AWS repo as it was from initial import. And I can see
the commit
on this one:
$ git log --all --parents | grep d2cf08bb67e4b7da33a250127aab784f1f2f58d3
commit bd95b2b254286e6f04015b7f58266d66abc134a7
d2cf08bb67e4b7da33a250127aab784f1f2f58d3
commit d2cf08bb67e4b7da33a250127aab784f1f2f58d3
406eaf7e51229f60048ea80cdb6904e33ef59a81
So that's definitely a problem with the filter-branch. Thanks a lot
for your precious help!
Will review the procedure for filtering branches :(
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCHv3/RFC 4/5] gitweb: Create links leading to 'blame_incremental' using JavaScript
From: Junio C Hamano @ 2009-11-12 8:05 UTC (permalink / raw)
To: Jakub Narebski
Cc: Petr Baudis, git, Fredrik Kuivinen, Giuseppe Bilotta,
Luben Tuikov, Martin Koegler
In-Reply-To: <200911061905.52285.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> But even if incremental blame turns out to be slower than incremental
> blame it still has the advantage of being _incremental_. You have at
> least some result soon.
It wasn't it was slow that bothered me, but early implementations of
incremental blame I tried didn't _appear_ as incremental. That was the
dissapointing part.
At the protocol and implementation level it certainly was feeding data
incrementally to the browser, but the end user experience on the screen
was "click....wait...wait...wait...voila the whole blame appears", not
"click...trickle...trickle...trickle...ah everything is filled". The
latter obviously is what an incremental one should be aiming for.
No I haven't tried your latest code. Probably I should.
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Junio C Hamano @ 2009-11-12 8:03 UTC (permalink / raw)
To: Raman Gupta; +Cc: git, Thomas Rast
In-Reply-To: <4AFB57A3.2020002@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
> Junio C Hamano wrote:
>>
>> Is this meant to show how git.git does its release to serve as an
>> inspiration to others? The document does not seem to describe how I make
>> releases.
>
> Here is the existing intro to gitworkflows:
>
> ===================
> This document attempts to write down and motivate some of the workflow
> elements used for git.git itself. Many ideas apply in general, though
> the full workflow is rarely required for smaller projects with fewer
> people involved.
>
> We formulate a set of rules for quick reference, while the prose tries
> to motivate each of them. Do not always take them literally; you
> should value good reasons for your actions higher than manpages such
> as this one.
> ===================
>
> It is in this spirit that I am attempting to add to this document in
> relation to the release process.
Thanks for reminding me of this.
Let me address the second paragraph from the quoted part first. The
existing document is structured as a quick reference. Rules and recipes,
with supporting prose to explain them (I do not think "motivate" is a good
way to phrase it, though).
I am not very fond of documents with that style, but that does not mean
nobody should work on nor we should ship such a document. It just means I
would not be a very good judge for one, and major parts of my response
unfortunately came from my bias against such a document.
What the first paragraph says is also important. We will talk about the
workflow elements we actually use here. Every description of a workflow
element should be read as if we said "this is what we use and it has
worked well for us; we recommend you to imitate it." after it. Limiting
the recommendation to what we practice ourselves and what worked well for
us keeps the document honest.
In that light, after I re-read your patch and my comments, I think I
should rescind large part of my comments on your "Release Tagging" section
and "Maintenance branch update" section. They are mostly good as-is, and
they are in line with the goal of the document stated at the beginning.
They describe the workflow elements actually used in git.git in a
quick-reference format.
>>> +RELEASE WORKFLOW
>>> +----------------
>>> +
>>> +The maintainer may use the following release workflow:
>>
>> Please set the tone straight. If this is to suggest various possible
>> workflows in general vague terms, "may use" would be good. ...
>
> Ok. The current document is inconsistent. In places it uses "the
> maintainer" and in other places it uses "you". In any case, it seems
> that the "maintainer" here is not "Junio Hamano" -- rather, it is the
> reader.
I wasn't talking about the difference between these two (Junio vs you).
That is not the issue. I was contrasting between
- You _may_ choose to do A for release management as the maintainer, or
do B or do C as alternatives.
and
- In managing git.git, its maintainer _does_ A when making a release.
As we are writing down what we practice, aka "workflow elements used for
git.git itself", in my comment I was hoping the latter was what you were
writing. Of course we could say
- In managing git.git, its maintainer _does_ A when making a release.
It is conceivable we _could_ also do B or C instead, but we do not
recommend them.
but I think we are better off without such an addition.
An anti-recommendation against B and C like that does not carry the same
weight as our positive recommendation for A, which is backed by our actual
experience.
"In the past, we tried B but it did not work well for us for such and such
reasons, so we don't recommend you to use B" would be justifiable, and
that is what I mean by "keeping the document honest by limiting the
description to what we use".
But if this document is meant to be a quick reference, such
anti-recommendation should be kept to minimum for the sake of
"quick"-ness.
Also I agree with you that ...
>> - review RelNotes symlink, Documentation/RelNotes-X.Y.Z.txt,
>> the stalenotes section in Documentation/git.git, and
>> GIT-VERSION-GEN for the last time;
>> - tag it;
>> - review it again for the last time;
>> - test on buildfarm;
>> - cut tarball;
>> - cut RPM on FC11 i386 and FC11 x86_64;
these (except "tag it") can safely omitted to keep the document focused on
"revision control" aspect of the system.
> The autobuilder is not git specific so should be excluded via the logic
> above -- except perhaps the hook part, which I could mention in general
> terms when discussing the push e.g.
>
> "You may decide to use a hook script on the public repository to
> initiate release-related items such as building documentation."
Again, if we are going to recommend it, we should say "We use post-update
hook in _this_ way", not "You may do ...".
A major difference is that we describe what has worked for us and exactly
how, as opposed to giving suggestions that we ourselves haven't even used
but suspect it might work in a hand-wavy way.
>>> +Maintenance branch update
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> ...
>>> +An alternative approach to updating the 'maint' branch is to run
>>> +
>>> + $ git branch -f maint master
>>
>> As I already said, I never do this "alternative", and I do not want
>> ...
>> mistake made. If you use "branch -f", you will never notice.
>
> I know you do not do this alternative, however ...
Given the stated goal of the document of showing what we actually do and
what we know have worked well for us, I do not think we would want it
mentioned as a valid alternative.
> previous discussion. I quote from
> http://article.gmane.org/gmane.comp.version-control.git/115183:
>
>>> I'll add some discussion about the branch -f bit -- I hope you agree
>>> that in this document that is distributed with git, some
>>> beginner-level explanation of the difference between the branch -f and
>>> the merge approach is warranted?
Explanation of the difference would have sounded like:
We do not use "branch -f maint master" here; it is different from
merging master into maint in such and such way and using "branch -f"
for this purpose only has downsides.
But is it really worth mentioning random approaches that novices might
think of as alternatives and then refuting every one of them? Should we
also say "don't do 'checkout maint && reset --hard master'"? Should we
say "'push . master:maint' would work equally well but don't add --force
to that command line"?
The document is an overview of recommended workflows. If we have one best
current practice for a task, just describing it without covering other
inferiour (or equivalent but not superiour) alternatives to clutter the
text would be better for such a "quick reference" document, I think.
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Junio C Hamano @ 2009-11-12 7:55 UTC (permalink / raw)
To: Thomas Rast
Cc: Nicolas Sebrecht, Baz, Peter Krefting, Git Mailing List,
Johannes Schindelin, Björn Steinbrink
In-Reply-To: <200911120037.11901.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Then again, I'm not sure if resolve vs. recursive makes a difference
> in a rebase. Octopus is weird for a two-head merge, I'm not sure why
...
> + If there is no `-s` option 'git-merge-recursive' is used
> + instead. This implies --merge.
> ++
> +Due to the peculiarities of 'git-rebase' (see \--merge above) the only
> +built-in strategy that is actually useful is 'subtree'.
"recursive is just a slower and sometimes buggier alternative to resolve
but can handle renames" may mean "people do not have much reason to choose
resolve over recursive". But that is quite different from "resolve is not
useful here _due to_ the peculiarities of rebase". Wouldn't anybody who
thinks "resolve vs. recursive would not make a difference in a rebase"
also think "resolve vs. recursive would not make a difference anywhere"?
58634db (rebase: Allow merge strategies to be used when rebasing,
2006-06-21) added "-m" and "-s" to rebase to solve the problem of rebasing
against an upstream that has moved files. What the commit actually did
was to use recursive (by default) while giving longer rope to the users by
choosing other strategies with "-s", without making any judgement as to
why other strategies may possibly be useful.
Perhaps there is some different issue at the root of this one. Why would
anybody be tempted to say "-s ours" while running a rebase? What did the
user want to see it do (instead of being a no-op because "ours" by
definition ignores the tree the change is replayed from)?
It is easy to dismiss it as a user misconception and it also is tempting
to think that it would be helped with updated description of "ours" to
dispel that misconception, but there may be some user wish that is totally
different from "ours merge" strategy but still can be validly labelled
using a word "ours" by somebody who does not know the way the word "ours"
is used in the git land, and satisfying that unknown user wish might be
the real solution to this issue.
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-12 7:11 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <4AFBADA9.3060401@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
>> Did you try an early version of Adam's patch before it made it into
>> git.git by any chance?
>
> No.
>
>> Or, did you by any chance start a fresh import with a v1.6.5 and then
>> rsync $GIT_DIR to one created with 1.6.4 and not use --delete with
>> rsync?
>
> No. The import has been done with 1.6.4. A filter-branch has been
> applied to fix author names. But AFAIK (will check) it has been done
> with 1.6.4 too.
Oh... Any chance that lost commit you couldn't find was clobbered
by filter-branch? That would explain a lot...
--
Eric Wong
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-12 6:39 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <20091111224454.GA16178@dcvr.yhbt.net>
Eric,
> Did you try an early version of Adam's patch before it made it into
> git.git by any chance?
No.
> Or, did you by any chance start a fresh import with a v1.6.5 and then
> rsync $GIT_DIR to one created with 1.6.4 and not use --delete with
> rsync?
No. The import has been done with 1.6.4. A filter-branch has been
applied to fix author names. But AFAIK (will check) it has been done
with 1.6.4 too.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: get git not to care about permissions
From: Jay Soffian @ 2009-11-12 5:44 UTC (permalink / raw)
To: sconeman; +Cc: git
In-Reply-To: <26268938.post@talk.nabble.com>
On Wed, Nov 11, 2009 at 4:17 PM, sconeman <schoen@bu.edu> wrote:
> does. Git doesn't like this and won't even create a bare repository. Is
> there any way I can get git to ignore permissions and just do what it needs
> to do?
And the output from "git init --bare" is?
j.
^ permalink raw reply
* Re: t5541-http-push hanging
From: Brian Gernhardt @ 2009-11-12 5:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git List
In-Reply-To: <20091112044906.GQ11919@spearce.org>
On Nov 11, 2009, at 11:49 PM, Shawn O. Pearce wrote:
> Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
>> My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
> ...
>> git clone $HTTPD_URL/smart/test_repo.git test_repo_clone
> ...
>> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
>> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
>
> I can't reproduce this on 10.5.8. Can you try running it in the
> debugger and putting a breakpoint where they suggest? Maybe it
> will help give us some context information:
>
> REQUEST_METHOD=GET \
> PATH_TRANSLATED=`pwd`/.git/info/refs \
> QUERY_STRING=service=git-upload-pack \
> gdb ./git-http-backend
>
> b malloc_error_break
> run
>
> I suspect that's where our failure is, the code path for the actual
> common negotiation and data transfer is shorter, and less likely
> to need to do a memory allocation... and therefore a free.
Interesting. This command runs to completion. In the test environment it gives:
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Type: application/x-git-upload-pack-advertisement
001e# service=git-upload-pack
0000009b0c973ae9bd51902a28466f3850b543fa66a6aaf4 HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed
003f0c973ae9bd51902a28466f3850b543fa66a6aaf4 refs/heads/master
0000
(which looks right to me)
access.log has:
127.0.0.1 - - [12/Nov/2009:04:54:38 +0000] "GET /smart/test_repo.git/info/refs?service=git-upload-pack HTTP/1.1" 200 256
127.0.0.1 - - [12/Nov/2009:04:54:38 +0000] "POST /smart/test_repo.git/git-upload-pack HTTP/1.1" 500 538
After a bit of trial and error, I got this:
test_repo.git (BARE:master)$ REQUEST_METHOD=POST PATH_TRANSLATED=`pwd`/git-upload-pack gdb ../../../../../git-http-backend GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ..
warning: Could not find object file "/sw/src/fink.build/libiconv-1.12-3/libiconv-1.12/lib/.libs/iconv.o" - no debug information available for "./iconv.c".
warning: Could not find object file "/sw/src/fink.build/libiconv-1.12-3/libiconv-1.12/lib/.libs/localcharset.o" - no debug information available for "./../libcharset/lib/localcharset.c".
warning: Could not find object file "/sw/src/fink.build/libiconv-1.12-3/libiconv-1.12/lib/.libs/relocatable.o" - no debug information available for "./relocatable.c".
.. done
(gdb) b malloc_error_break
Breakpoint 1 at 0x4189374bb86951
(gdb) run
Starting program: /Users/brian/dev/git/git-http-backend
Reading symbols for shared libraries +++. done
git-http-backend(2358) malloc: *** error for object 0x100200390: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Breakpoint 1, 0x00007fff84c19951 in malloc_error_break ()
(gdb) bt
#0 0x00007fff84c19951 in malloc_error_break ()
#1 0x00007fff84c1aaa8 in szone_error ()
#2 0x00007fff84b466e3 in tiny_free_list_remove_ptr ()
#3 0x00007fff84b44df7 in szone_realloc ()
#4 0x00007fff84b44b3b in malloc_zone_realloc ()
#5 0x00007fff84b50bd3 in realloc ()
#6 0x000000010004985f in xrealloc (ptr=0x100200370, size=66) at wrapper.c:59
#7 0x0000000100041372 in strbuf_grow (sb=0x7fff5fbfed70, extra=<value temporarily unavailable, due to optimizations>) at strbuf.c:61
#8 0x000000010001e194 in strbuf_addch [inlined] () at /Users/brian/dev/git/strbuf.h:95
#9 0x000000010001e194 in add_path (out=0x7fff5fbfed70, path=0x100200320 "/usr/local/libexec/git-core") at exec_cmd.c:95
#10 0x000000010001e229 in setup_path () at exec_cmd.c:104
#11 0x000000010000226d in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at http-backend.c:641
(gdb)
I'm lost as to why it's dying doing setup_path. My guess is that some of the code before here is doing something bad to memory.
~~ Brian
^ permalink raw reply
* Re: t5541-http-push hanging
From: Shawn O. Pearce @ 2009-11-12 4:49 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <B17AB159-E217-4E1F-BEA3-97E5892C13F4@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
...
> git clone $HTTPD_URL/smart/test_repo.git test_repo_clone
...
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
I can't reproduce this on 10.5.8. Can you try running it in the
debugger and putting a breakpoint where they suggest? Maybe it
will help give us some context information:
REQUEST_METHOD=GET \
PATH_TRANSLATED=`pwd`/.git/info/refs \
QUERY_STRING=service=git-upload-pack \
gdb ./git-http-backend
b malloc_error_break
run
I suspect that's where our failure is, the code path for the actual
common negotiation and data transfer is shorter, and less likely
to need to do a memory allocation... and therefore a free.
--
Shawn.
^ permalink raw reply
* [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length
From: Shawn O. Pearce @ 2009-11-12 4:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tarmigan, git
In-Reply-To: <905315640911100910r5116779eh24796fa5788f4aef@mail.gmail.com>
Our Content-Length needs to report an off_t, which could be larger
precision than size_t on this system (e.g. 32 bit binary built with
64 bit large file support).
We also shouldn't be passing a size_t parameter to printf when
we've used PRIuMAX as the format specifier.
Fix both issues by using uintmax_t for the hdr_int() routine,
allowing strbuf's size_t to automatically upcast, and off_t to
always fit.
Also fixed the copy loop we use inside of send_local_file(), we never
actually updated the size variable so we might as well not use it.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Tarmigan <tarmigan+git@gmail.com> wrote:
> unhappy. Curl returns 18 (CURLE_PARTIAL_FILE), the test takes a long
> time to fail, and the "out" file looks OK (compared to a linux machine
> where the test passes) expect for "Content-Length: 37847251812411".
>
> Digging into it a bit more with gdb, the call to hdr_int() in
> http-backend.c looks OK, but then something goes wrong in
> format_write(). Hmmm it looks like my setup does not like PRIuMAX
> with size_t, which puts some garbage in the upper bytes of
Yup, only the right fix is to keep using PRIuMAX... patch below.
http-backend.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index f8ea9d7..7f48406 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -134,7 +134,7 @@ static void hdr_str(const char *name, const char *value)
format_write(1, "%s: %s\r\n", name, value);
}
-static void hdr_int(const char *name, size_t value)
+static void hdr_int(const char *name, uintmax_t value)
{
format_write(1, "%s: %" PRIuMAX "\r\n", name, value);
}
@@ -216,7 +216,6 @@ static void send_local_file(const char *the_type, const char *name)
char *buf = xmalloc(buf_alloc);
int fd;
struct stat sb;
- size_t size;
fd = open(p, O_RDONLY);
if (fd < 0)
@@ -224,14 +223,12 @@ static void send_local_file(const char *the_type, const char *name)
if (fstat(fd, &sb) < 0)
die_errno("Cannot stat '%s'", p);
- size = xsize_t(sb.st_size);
-
- hdr_int(content_length, size);
+ hdr_int(content_length, sb.st_size);
hdr_str(content_type, the_type);
hdr_date(last_modified, sb.st_mtime);
end_headers();
- while (size) {
+ for (;;) {
ssize_t n = xread(fd, buf, buf_alloc);
if (n < 0)
die_errno("Cannot read '%s'", p);
--
1.6.5.2.351.g09432
^ permalink raw reply related
* Re: t5541-http-push hanging
From: Shawn O. Pearce @ 2009-11-12 4:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <B17AB159-E217-4E1F-BEA3-97E5892C13F4@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
...
> Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo_clone/.git/
> error: RPC failed; result=22, HTTP code = 500
> ^CFATAL: Unexpected exit with code 130
...
>
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
> [Wed Nov 11 06:19:40 2009] [error] [client 127.0.0.1] Premature end of script headers: git-http-backend
Probably caused by a missing cast:
diff --git a/http-backend.c b/http-backend.c
index f8ea9d7..957e4ef 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -136,7 +136,7 @@ static void hdr_str(const char *name, const char *value)
static void hdr_int(const char *name, size_t value)
{
- format_write(1, "%s: %" PRIuMAX "\r\n", name, value);
+ format_write(1, "%s: %" PRIuMAX "\r\n", name, (uintmax_t)value);
}
static void hdr_date(const char *name, unsigned long when)
--
Shawn.
^ permalink raw reply related
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