* [PATCH] mktree: fix a memory leak in write_tree()
From: Liu Yuan @ 2011-11-10 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: Liu Yuan <tailai.ly@taobao.com>
We forget to call strbuf_release to release the buf memory.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
---
builtin/mktree.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin/mktree.c b/builtin/mktree.c
index 098395f..4ae1c41 100644
--- a/builtin/mktree.c
+++ b/builtin/mktree.c
@@ -60,6 +60,7 @@ static void write_tree(unsigned char *sha1)
}
write_sha1_file(buf.buf, buf.len, tree_type, sha1);
+ strbuf_release(&buf);
}
static const char *mktree_usage[] = {
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH 02/14] http: turn off curl signals
From: Daniel Stenberg @ 2011-11-10 8:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111110074803.GB27950@sigill.intra.peff.net>
On Thu, 10 Nov 2011, Jeff King wrote:
> I'm a little iffy on this one. If I understand correctly, depending on the
> build and configuration, curl may not be able to timeout during DNS lookups.
> But I'm not sure if it does, anyway, since we don't set any timeouts.
Right, without a timeout set libcurl won't try to timeout name resolves.
To clarify: when libcurl is built to use the standard synchronous name
resolver functions it can only abort them after a specified time by using
signals (on posix systems).
--
/ daniel.haxx.se
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: Nathan Broadbent @ 2011-11-10 8:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4EBB78C7.101@viscovery.net>
So, this is a feature, not a bug... Tab completion for aliases is
really useful. It's important enough to me that I won't stop until
I've found a solution.
I can appreciate that _git_fetch is not currently meant to be called
directly, but we found a way to utilize it when it previously worked.
Perhaps the scope of these completion functions could be expanded to
allow for aliases? I'll attempt to submit a patch if someone can give
me approval.
Thanks,
Nathan
On Thu, Nov 10, 2011 at 3:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
> Am 11/10/2011 4:21, schrieb Junio C Hamano:
> > Nathan Broadbent <nathan.f77@gmail.com> writes:
> >
> >> Dear git mailing list,
> >>
> >> I'm assigning the `_git_fetch` bash tab completion to the alias `gf`,
> >> with the following command:
> >>
> >> complete -o default -o nospace -F _git_fetch gf
> >>
> >> The tab completion then works fine in git 1.7.0.4, but breaks on git
> >> 1.7.7.1, with the following error:
> >
> > We have been cooking for 1.7.8 and have the first release candidate
> > 1.7.8-rc1; could you try it and report what you find out?
>
> It looks like _git_fetch is not meant to be called directly. All git
> completions must go through _git.
>
> See also this post:
>
> http://thread.gmane.org/gmane.comp.version-control.msysgit/13310/focus=13335
>
> -- Hannes
^ permalink raw reply
* [PATCH] mktree: fix a memory leak in write_tree()
From: Liu Yuan @ 2011-11-10 9:04 UTC (permalink / raw)
To: git
From: Liu Yuan <tailai.ly@taobao.com>
We forget to call strbuf_release to release the buf memory.
Signed-off-by: Liu Yuan <tailai.ly@taobao.com>
---
builtin/mktree.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin/mktree.c b/builtin/mktree.c
index 098395f..4ae1c41 100644
--- a/builtin/mktree.c
+++ b/builtin/mktree.c
@@ -60,6 +60,7 @@ static void write_tree(unsigned char *sha1)
}
write_sha1_file(buf.buf, buf.len, tree_type, sha1);
+ strbuf_release(&buf);
}
static const char *mktree_usage[] = {
--
1.7.6.1
^ permalink raw reply related
* Re: RFH: unexpected reflog behavior with --since=
From: Miles Bader @ 2011-11-10 11:06 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Raible, git@vger.kernel.org
In-Reply-To: <20111110080851.GA28342@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The only point would be to leave "--since" to act on the commit
> timestamps, so that you don't have to resort to the external grepping I
> mentioned above. However, I'm not convinced anybody even cares about
> that use case.
>
> I think the behavior you want is much more sensible.
I think there's already confusion in this area, e.g., with @{...} using
reflog dates, but "git log --since" using commit dates. This can be an
easy trap to fall into because _often_ the two have similar granularity
(when you're mostly pushing changes), but not _always_ (when you pull a
big batch of changes).
Soooo, being really really explicit about using reflog dates vs. commit
dates -- and e.g., having option names like "--since" _always_ refer to
commit dates -- would be a good thing, I think...
-Miles
--
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.
^ permalink raw reply
* Re: [fyi] patches used by git distributors
From: Erik Faye-Lund @ 2011-11-10 12:07 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111108090251.GB17954@elie.hsd1.il.comcast.net>
On Tue, Nov 8, 2011 at 10:02 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> In an ideal world, each patch applied by downstream distributors would
> fall into one of two categories: (a) adapting the package to some
> esoteric distro-specific requirement (i.e., special-interest patches)
> or (b) in the process of being generalized and reviewed for eventual
> application upstream, so everyone can benefit from it. Unfortunately
> that takes time. I should do better --- sorry about that.
>
> As an experiment, here's a quick summary of the patches being used
> in Debian, for people curious about that and for people interested in
> grabbing useful patches to polish and not knowing where to start.
>
> (Links point to relevant discussion, not necessarily the patch used):
>
> Frédéric Brière (1):
> gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields [1]
>
> Gerrit Pape (1):
> bug#506445: hooks/post-receive-email: set encoding to utf-8 [2]
>
> Jonathan Nieder (12):
> remove shebang line from shell libraries [3]
> pre-rebase hook: capture documentation in a <<here document [4]
> gitk: use symbolic font names "sans" and "monospace"
> transport: expose git_tcp_connect and friends in new tcp.h [5]
> daemon: make host resolution into a separate function [5]
> daemon: move locate_host to tcp.c [5]
> tcp: unify ipv4 and ipv6 code paths [5]
> daemon: check for errors retrieving IP address [5]
> tcp: make dns_resolve return an error code [5]
> transport: optionally honor DNS SRV records [5]
> srv: make errors less quiet [5]
> Makefile: add a knob to turn off hardlinks within same directory [6]
>
> The patches listed above are on the candidate+patches branch of [7].
> Questions and improvements can go to git@packages.debian.org.
>
> A few other packaging projects:
>
> - git://pkgs.fedoraproject.org/git.git master --- 3 patches (using
> SERVER_NAME for home link, reviving vc-git.el, compatibility with
> newer cvsps)
> - http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/git/files/ ---
> 1 patch (capping individual reads and writes at INT_MAX chars)
> - https://build.opensuse.org/package/files?package=git&project=devel%3Atools%3Ascm
> --- 4 patches (a python build fix, making gitweb::prevent_xss
> default to true, turning off hardlinks for builtins at installation
> time, protecting COMP_WORDBREAKS from mangling in the completion
> script)
> - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-vcs/git/files/
> --- 1 patch (a NO_CVS knob for the makefile). Very nice.
> - http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/scmgit-base/patches/
> --- 3 patches (putting CFLAGS at the end of ALL_CFLAGS so it can
> override BASIC_CFLAGS, setting INSTALLDIRS=vendor in perl makefile,
> improving tk support on Darwin 8)
> - http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/git/patches/ ---
> 8 patches (updating OpenBSD makefile defaults, using raw perlio in
> gitweb blob view, removing "set -e" in t9117, passing --text [well,
> -a] to grep in t9200, avoiding nonportable regex \+ in t9400)
> - ftp://ftp.cygwin.org/pub/cygwin/release/git/git-1.7.5.1-1-src.tar.bz2
> --- 3 patches (tcl 8.4.1 support, updating Cygwin makefile defaults,
> case-insensitive path comparison in makefile, special Windows-specific
> wish script preamble)
>
Here's what we have for msysGit (the commits themselves can be found
in git://github.com/msysgit/git.git devel):
$ git log --no-merges --first-parent --oneline 319312f..origin/devel
9e47e31 Unicode console: fix font warning on Vista and Win7
778774d MSVC: require pton and ntop emulation
a49c818 MSVC: fix winansi.c compile errors
9ca8039 MSVC: fix poll-related macro redefines
0a6d148 MSVC: Remove unneeded header stubs
18f5b9e Compile fix for MSVC: Include <io.h>
fd6f6aa Compile fix for MSVC: Do not include sys/resources.h
ae69aaf Handle the branch.<name>.rebase value 'interactive'
5d1168b Teach 'git pull' to handle --rebase=interactive
5d6f1d9 Windows: define S_ISUID properly
5084033 Fixed wrong path delimiter in exe finding
77a30da gitweb (SyntaxHighlighter): interpret #l<line-number>
4654bdd Only switch on the line number toggle when highlighting is activated
3efcd98 Gitweb: add support for Alex Gorbatchev's SyntaxHighlighter in
Javascript
1d9ac66 MinGW: disable CRT command line globbing
e0f2492 Win32: move main macro to a function
8258c82 Win32: fix potential multi-threading issue
c45b052 Win32 dirent: improve dirent implementation
ab7ab7a Win32 dirent: clarify #include directives
9d46513 Win32 dirent: change FILENAME_MAX to MAX_PATH
18cf321 Win32 dirent: remove unused dirent.d_reclen member
2741409 Win32 dirent: remove unused dirent.d_ino member
a27af5c Revert "MinGW: Add missing file mode bit defines"
3e4b790 submodule: Fix t7400, t7405, t7406 for msysGit
f72cc9a t5407: Fix line-ending dependency in post-rewrite.args
77de716 submodule: Use cat instead of echo to avoid DOS line-endings
fece0cb t3102: Windows filesystems may not use a literal asterisk in filenames.
d3abd84 Disable test on MinGW that challenges its bash quoting
3f65607 MinGW: Skip test redirecting to fd 4
2e1f250 mingw: do not hide bare repositories
8089c85c Git.pm: Use stream-like writing in cat_blob()
d3d677e Amend "git grep -O -i: if the pager is 'less', pass the '-i' option"
ed7b275 git grep -O -i: if the pager is 'less', pass the '-i' option
30d3f9e Handle new t1501 test case properly with MinGW
64f7bec Do not compile compat/**/*.c with -Wold-style-definition
68acf50 Fix old-style function declaration
aa1c11f Make CFLAGS more strict
c592e94 grep -I: do not bother to read known-binary files
352f3d0 Let deny.currentBranch=updateInstead ignore submodules
5cf00b3 add -e: ignore dirty submodules
bf239f8 Handle http.* config variables pointing to files gracefully on Windows
621a958 Gitweb: make line number toggling work for Firefox and Safari
ff19df4 gitweb: Allow line number toggling with Javascript
feab003 Give commit message reencoding for output on MinGW a chance
6f86c3e Warn if the Windows console font doesn't support Unicode
bfcdc94 Detect console streams more reliably on Windows
9b505ab Support Unicode console output on Windows
e3356ac Enable color output in Windows cmd.exe
3bef266 Fix another invocation of git from gitk with an overly long command-line
d0a4bbe git gui: set GIT_ASKPASS=git-gui--askpass if not set yet
7602e52 Make mingw_offset_1st_component() behave consistently for all paths.
1c072a6 config.c: trivial fix for compile-time warning
1f3a4f8 Allow using UNC path for git repository
3d08379 work around misdetection of stdin attached to a tty
fef92f8 git am: ignore dirty submodules
d23ce6f t7602: cope with CR/LF
3649391 Add a Windows-specific fallback to getenv("HOME");
ede54b1 send-email: handle Windows paths for display just like we do
for processing
32eefc4 send-email: accept absolute path even on Windows
6274596 Add a few more values for receive.denyCurrentBranch
2afff36 Work around funny CR issue
b81e593 mingw: add tests for the hidden attribute on the git directory
f9445e4 Work around the command line limit on Windows
59e0e60 git-gui: provide question helper for retry fallback on Windows
9e89381 Revert "git-gui: set GIT_DIR and GIT_WORK_TREE after setup"
40e6ef7 criss cross rename failure workaround
d24ec01 When initializing .git/, record the current setting of core.hideDotFiles
c40046b core.hidedotfiles: hide '.git' dir by default
73afc46 MinGW: Add missing file mode bit defines
Some of these might be useful for upstream as well...
^ permalink raw reply
* Disappearing change on pull rebase
From: Pitucha, Stanislaw Izaak @ 2011-11-10 13:15 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hi all,
I've got an issue with some operations. It seems like git eats one of my commits (it's still in reflog, but in normal tree, it's unavailable).
What I did is:
checkout -b feature/....
(edit files and commit)
checkout master
merge --no-ff --no-commit feature/...
(edit some files, change versions, changelog)
commit
Now I've got the change committed in the branch and some more changes on the merge commit.
So before pushing to the main repo, I'd like to check if any other changes are there:
pull --rebase
Now my merge commit disappears completely along with the changes without any warning. I get the branch commits duplicated on top of master and the branch stays as it was.
That looks like a data loss bug to me since I can only recover a committed change from reflog and there are no warnings before that change goes away (using 1.7.4.1). Actually no changes were done in upstream in the meantime, so the rebase was not even needed.
Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6216 bytes --]
^ permalink raw reply
* Re: Disappearing change on pull rebase
From: Kirill Likhodedov @ 2011-11-10 14:23 UTC (permalink / raw)
To: Pitucha, Stanislaw Izaak; +Cc: git@vger.kernel.org
In-Reply-To: <3FF1328CB05DB74898F769F1BA17812C3E49B74671@GVW1348EXA.americas.hpqcorp.net>
10.11.2011, в 16:15, Pitucha, Stanislaw Izaak:
> Hi all,
> I've got an issue with some operations. It seems like git eats one of my commits (it's still in reflog, but in normal tree, it's unavailable).
>
> What I did is:
>
> checkout -b feature/....
> (edit files and commit)
> checkout master
> merge --no-ff --no-commit feature/...
> (edit some files, change versions, changelog)
> commit
>
> Now I've got the change committed in the branch and some more changes on the merge commit.
> So before pushing to the main repo, I'd like to check if any other changes are there:
>
> pull --rebase
>
> Now my merge commit disappears completely along with the changes without any warning. I get the branch commits duplicated on top of master and the branch stays as it was.
> That looks like a data loss bug to me since I can only recover a committed change from reflog and there are no warnings before that change goes away (using 1.7.4.1). Actually no changes were done in upstream in the meantime, so the rebase was not even needed.
>
That is definitely not a bug.
"git pull --rebase" is (almost?) equal to "git fetch ; git rebase origin/master"
When you perform a rebase, at first your HEAD is rolled back to the commit before your changes, then it is fast-forwared to the remote HEAD (in your case, no fast-forward was made, because there were no remote changes); then your commits are applied one by one.
Of couse, when your commits are applied, they are applied like patches. That mean, that they are different from the original commits (at least, by the commit time). That causes the duplication.
And the merge commit "dissapeared", because it contained no changes, so the patch was empty, and there was nothing to reapply.
If the merge commit contained some changes, and it really was not applied during rebase, it is a bug, but more details will be needed, I think.
If you want to preserve your branch history, you should do "pull" without "rebase".
Kirill.
^ permalink raw reply
* RE: Disappearing change on pull rebase
From: Pitucha, Stanislaw Izaak @ 2011-11-10 13:35 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <B5934593-5EE9-4A9F-96D5-0E36B696EFBD@jetbrains.com>
[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]
As mentioned in the original mail - the merge commit did have changes. Here's the log of reproducing it. The line containing "2" in changelog is gone from master after pull --rebase.
$ git init fake_upstream
Initialized empty Git repository in /tmp/fake_upstream/.git/
$ cd fake_upstream/
fake_upstream$ echo some_content > test
fake_upstream$ echo 1 > changelog
fake_upstream$ git add test changelog
fake_upstream$ git commit -m 'first commit'
[master (root-commit) b1b683d] first commit
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 changelog
create mode 100644 test
fake_upstream$ cd ..
$ git clone /tmp/fake_upstream/ disappearing_commit
Cloning into disappearing_commit...
done.
$ cd disappearing_commit/
disappearing_commit$ git checkout -b some-branch
Switched to a new branch 'some-branch'
disappearing_commit$ echo blah >> test
disappearing_commit$ git commit test -m 'branch modification'
[some-branch 528f166] branch modification
1 files changed, 1 insertions(+), 0 deletions(-)
disappearing_commit$ git checkout master
Switched to branch 'master'
disappearing_commit$ git merge --no-ff --no-commit some-branch
Automatic merge went well; stopped before committing as requested
disappearing_commit$ echo 2 >> changelog
disappearing_commit$ git add changelog
disappearing_commit$ git commit
[master e41e4c9] Merge branch 'some-branch'
disappearing_commit$ git show
commit e41e4c963a72528e3b2b5945ca419e19cdba1e4b
Merge: b1b683d 528f166
Author: Stanislaw Pitucha <stanislaw.pitucha@hp.com>
Date: Thu Nov 10 13:30:04 2011 +0000
Merge branch 'some-branch'
diff --cc changelog
index d00491f,d00491f..1191247
--- a/changelog
+++ b/changelog
@@@ -1,1 -1,1 +1,2 @@@
1
++2
disappearing_commit$ git pull --rebase
First, rewinding head to replay your work on top of it...
Applying: branch modification
disappearing_commit$ git show
commit ef8f5e40db9fe7efbd4e493ff68b12327acde283
Author: Stanislaw Pitucha <stanislaw.pitucha@hp.com>
Date: Thu Nov 10 13:29:33 2011 +0000
branch modification
diff --git a/test b/test
index 6e099dc..2f3f685 100644
--- a/test
+++ b/test
@@ -1 +1,2 @@
some_content
+blah
Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6216 bytes --]
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: David Woodhouse @ 2011-11-10 13:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jochen Striepe, Shawn Pearce, Junio C Hamano, git,
James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyG4VuiRN3kcyDVF4sw7b89m-2bOBeQLOGWTcd9o3akzQ@mail.gmail.com>
On Wed, 2011-11-02 at 21:13 -0700, Linus Torvalds wrote:
> No, my main objection to saving the data is that it's ugly and it's
> redundant. Sure, in practice you can check the signatures later fine
> (with the rare exceptions you mention), but even when you can do it,
> what's the big upside?
Another objection (although it may not be insurmountable) is that it's
not necessarily *entirely* clear what's being signed.
In the simple case where I clone your tree, make a few commits with my
Signed-off-by:, sign a tag and then ask you to pull, that's easy enough.
I'm vouching for what I committed, and not for everything that was in
your tree beforehand.
But what if I'm working on top of someone else's published git tree?
Does a signed tag at the top of *my* work imply that I'm vouching for
all of theirs too?
In the case where the signature is ephemeral and only used for you to
trust my pull request, the answer is simple: If that other work wasn't
in your tree yet at the time I send my pull request, I'd damn well
better be vouching for it when I ask you to pull it. Nothing new there.
But if we're keeping signatures around for auditing purposes, we'd
better have a coherent answer to that question. One that isn't "a
signature cover everything since the last commit with torvalds@ as the
committer", if we want it to be useful for the general case.
--
dwmw2
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: David Woodhouse @ 2011-11-10 13:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFx_rAA6TJkZn1Zvu6u9UjxnmTVt0HpMnvaE_q9Sx-jzPg@mail.gmail.com>
On Tue, 2011-11-01 at 14:21 -0700, Linus Torvalds wrote:
> 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.
I actually quite like it. I take it as a hint: if the contents of a
branch are *so* wildly different from the main repository that they need
a different description, perhaps I should be using a separate repository
instead of just a branch.
--
dwmw2
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: Nathan Broadbent @ 2011-11-10 14:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAPXHQbP2O2C6sDVYLB=eMu0UpdMm79t3fqopqBvNpmdpKPRsXQ@mail.gmail.com>
> No change with 1.7.8-rc1, tab completion still fails
^ permalink raw reply
* Re: Bash tab completion for _git_fetch alias is broken on Git 1.7.7.1
From: SZEDER Gábor @ 2011-11-10 15:14 UTC (permalink / raw)
To: Nathan Broadbent; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <CAPXHQbP4yCzZ96WEKuHsV_8Pny0MRzcLOY7qi5W3_L_5CnY0vA@mail.gmail.com>
Hi,
[Please don't top-post.]
> On Thu, Nov 10, 2011 at 3:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >
> > Am 11/10/2011 4:21, schrieb Junio C Hamano:
> > > Nathan Broadbent <nathan.f77@gmail.com> writes:
> > >
> > >> Dear git mailing list,
> > >>
> > >> I'm assigning the `_git_fetch` bash tab completion to the alias `gf`,
> > >> with the following command:
> > >>
> > >> complete -o default -o nospace -F _git_fetch gf
I assume you have an
alias gf="git fetch"
somewhere, right?
> > >> The tab completion then works fine in git 1.7.0.4, but breaks on git
> > >> 1.7.7.1, with the following error:
I didn't actually tried, but I guess this is a side-effect of da4902a7
(completion: remove unnecessary _get_comp_words_by_ref() invocations,
2011-04-28), which was in v1.7.6. Since the clean-up in that commit
we only call _get_comp_words_by_ref() in the top-level completion
functions _git() and _gitk() to populate completion-related variables
($cur, $prev, $words, $cword), so invoking any _git_<cmd>() completion
function directly causes an error or wrong behavior, because all those
variables are empty.
Calling a completion function directly was not an issue earlier,
because every _git_<cmd>() completion function invoked
_get_comp_words_by_ref() to populate those variables, or in the
pre-_get_comp_words_by_ref() times they just accessed the
completion-related bash variables $COMP_WORDS and $COMP_CWORD
directly.
On Thu, Nov 10, 2011 at 04:52:33PM +0800, Nathan Broadbent wrote:
> So, this is a feature, not a bug... Tab completion for aliases is
> really useful. It's important enough to me that I won't stop until
> I've found a solution.
> I can appreciate that _git_fetch is not currently meant to be called
> directly, but we found a way to utilize it when it previously worked.
> Perhaps the scope of these completion functions could be expanded to
> allow for aliases? I'll attempt to submit a patch if someone can give
> me approval.
The quickest way would be to just revert da4902a7, but it would be the
dirtiest, too: it would bring back a lot of redundant calls to
_get_comp_words_by_ref() and it might have side-effects under zsh (but
I didn't think this through).
It would be a bit more clever to revert only parts of da4902a7, i.e.
to bring back _get_comp_words_by_ref() calls in _git_<cmd> completion
functions but not in __git_<whatever>() helper functions. This way
_git_<cmd>() functions would have their completion-related variables
initialized even when called directly instead through _git(), and
_get_comp_words_by_ref() would be called "only" twice during a single
completion. But that's still one too many, and again: there can be
issues with zsh.
Alternatively, you could easily create your own wrapper function
around _git_fetch(), like this:
_gf () {
local cur prev words cword
_get_comp_words_by_ref -n =: cur prev words cword
_git_fetch
}
However.
Having said all that, I'd like to point out that even if _git_fetch()
didn't error out when called for the 'gf' alias, it still wouldn't
work properly. After 'gf origin <TAB>' it offers the list of remotes
again and it never offers refspecs, because it calls
__git_complete_remote_or_refspec(), which
- depends on the fact that there must be at least two words ('git'
and 'fetch') on the command line before the remote, and
- needs to know the git command (i.e. fetch, pull, or push) to offer
the proper refspecs, but it can't find that out from your alias.
Best,
Gábor
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-10 15:15 UTC (permalink / raw)
To: Johan Herland
Cc: Linus Torvalds, Ted Ts'o, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CALKQrgfZtELcK3H5ZYvmcW8RrtKMVRACFTvw3s5SidFvmFWkGw@mail.gmail.com>
Johan Herland <johan@herland.net> writes:
> On Wed, Nov 9, 2011 at 18:26, Junio C Hamano <gitster@pobox.com> wrote:
>> - "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.
>
> True. However, consider these mitigating factors:
> ...
>
> My point is that although "notes" might end up transferring more
> annotations than strictly necessary, I believe that in practice all the
> notes being transferred are already (or will soon become) relevant.
Sorry, but I do not think you are considering what would happen when you
have many branches with different purposes, whose commits near tips will
never get merged with each other. "automatic following" semantics like
what "git fetch" does for signed tags is absolutely necessary in such a
case, and the above are not mitigating factors at all in that context.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Marc Branchaud @ 2011-11-10 15:23 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Jochen Striepe, Shawn Pearce, Junio C Hamano, git,
James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <1320933118.17392.23.camel@i7.infradead.org>
On 11-11-10 08:51 AM, David Woodhouse wrote:
> On Wed, 2011-11-02 at 21:13 -0700, Linus Torvalds wrote:
>> No, my main objection to saving the data is that it's ugly and it's
>> redundant. Sure, in practice you can check the signatures later fine
>> (with the rare exceptions you mention), but even when you can do it,
>> what's the big upside?
>
> Another objection (although it may not be insurmountable) is that it's
> not necessarily *entirely* clear what's being signed.
I think this is a non-issue as far as the implementation is concerned. That
is, the question exists regardless of what actual bits get (hashed and)
encrypted by a private key. Furthermore, the answer will depend on who's
using the signatures and in what context, and it's not appropriate for the
git tool to make assumptions about those things.
> In the simple case where I clone your tree, make a few commits with my
> Signed-off-by:, sign a tag and then ask you to pull, that's easy enough.
> I'm vouching for what I committed, and not for everything that was in
> your tree beforehand.
>
> But what if I'm working on top of someone else's published git tree?
> Does a signed tag at the top of *my* work imply that I'm vouching for
> all of theirs too?
<philosophy>
It all depends on what you mean by "vouch for".
You obviously thought that the 3rd-party repo was good for something,
otherwise why did you base your work on it in the first place? So maybe
you're just vouching for the 3rd-party repo being good enough for what you're
trying to do.
Or, maybe you've done a thorough analysis of the 3rd-party code and are ready
to certify it as completely memory-leak-free or something.
Or or, maybe you're only making a statement about the commits that you've
authored yourself. (You probably want to individually sign each of those
commits in this case.)
These sorts of issues have been debated on PKI mailing lists ad nauseum. I
think the best approach is that if you want your signature to have a
particular meaning, then put that into some text that's part of what's being
signed. Let other humans read that text and make their own decisions.
</philosophy>
And whatever the case, the software that makes and validates the signatures
shouldn't make any assertions about how to interpret good or bad signatures.
(Yes, other software could interpret meanings according to some criteria,
and that software could exist alongside or be incorporated into the basic
digital signature software, but the interpretation software is doing a
different job.)
M.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Johan Herland @ 2011-11-10 16:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Ted Ts'o, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <7vaa84t3ek.fsf@alter.siamese.dyndns.org>
On Thu, Nov 10, 2011 at 16:15, Junio C Hamano <junio@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>> On Wed, Nov 9, 2011 at 18:26, Junio C Hamano <gitster@pobox.com> wrote:
>>> - "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.
>>
>> True. However, consider these mitigating factors:
>> ...
>>
>> My point is that although "notes" might end up transferring more
>> annotations than strictly necessary, I believe that in practice all the
>> notes being transferred are already (or will soon become) relevant.
>
> Sorry, but I do not think you are considering what would happen when you
> have many branches with different purposes, whose commits near tips will
> never get merged with each other. "automatic following" semantics like
> what "git fetch" does for signed tags is absolutely necessary in such a
> case, and the above are not mitigating factors at all in that context.
What about having one notes ref per branch? If/when the branch is merged,
the associated notes ref containing the annotations for the commits on that
branch would be merged as well (using "git notes merge").
Sure, using one notes ref per branch is more expensive than a single notes
ref, but it's still cheaper than one ref per signed commit (which is what we
get when using annotated tags). And it prevents the added code and
complexity of the timestamped mapping approach.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* "make quick-install-man" on git.git HEAD has failed for two days
From: Randal L. Schwartz @ 2011-11-10 16:17 UTC (permalink / raw)
To: git
Known issue? Should I have done something differently?
"make install quick-install-man" ends with:
make[2]: `GIT-VERSION-FILE' is up to date.
git-manpages repository must exist at ../../git-manpages
make[1]: *** [require-manrepo] Error 1
make: *** [quick-install-man] Error 2
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: [fyi] patches used by git distributors
From: Todd Zullinger @ 2011-11-10 16:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111108090251.GB17954@elie.hsd1.il.comcast.net>
[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]
Hi Jonathan,
Thanks for putting this together.
Jonathan Nieder wrote:
> In an ideal world, each patch applied by downstream distributors would
> fall into one of two categories: (a) adapting the package to some
> esoteric distro-specific requirement (i.e., special-interest patches)
> or (b) in the process of being generalized and reviewed for eventual
> application upstream, so everyone can benefit from it. Unfortunately
> that takes time. I should do better --- sorry about that.
> A few other packaging projects:
>
> - git://pkgs.fedoraproject.org/git.git master --- 3 patches (using
> SERVER_NAME for home link, reviving vc-git.el, compatibility with
> newer cvsps)
To review the patches we have in Fedora/EPEL:
- git-1.5-gitweb-home-link.patch¹
This predates my involvement in git packaging. The default for
++GITWEB_HOME_LINK_STR++ is projects. The patch just uses
git://$SERVER_NAME if SERVER_NAME is available, falling back to
projects if it is not.
I'm not sure exactly why that's an improvement over using projects, to
be honest. It's only a text string and it links to the gitweb home,
not to the contents of the string, so whether it reads projects or
git://$SERVER_NAME it takes the user to the same place. Definitely
doesn't seem like something we'd want to push into gitweb and I'm
wondering why we even want to carry it in Fedora/EPEL at this point in
the morning. :)
- git-1.7-el5-emacs-support.patch²
This is only applied to builds for EL-5, where emacs is too old for
the current emacs git support. From the commit message:
This is the vc-git.el from 1.6.4.1, the last version to include
it. Most uses will be better served by the vc-git.el which is
provided by emacs >= 22.2, but on EL-5 we don't have the luxury of
a modern emacs.
Basically, to not break emacs support for folks who were using
git-1.5.x from EPEL, we had to provide something to allow us to push
git-1.7.x. It seems there are relatively few emacs-git users running
EL-5, as getting testers for this was difficult. At the same time,
we've gotten 0 bug reports. So it either works about as well as it
did with git-1.5.x or no one uses it to notice that it doesn't work.
- git-cvsimport-Ignore-cvsps-2.2b1-Branches-output.patch³
This one became necessary when Fedora moved to cvsps 2.2b1 and git
cvsimport got noisy⁴. As cvsps is pretty much dead upstream, it didn't
seem like this patch was worthy of inclusion in git.
If any of these seem like candidates for inclusion, I'm happy to
properly submit them.
¹ http://pkgs.fedoraproject.org/gitweb/?p=git.git;a=blob;f=git-1.5-gitweb-home-link.patch;hb=HEAD
² http://pkgs.fedoraproject.org/gitweb/?p=git.git;a=blob;f=git-1.7-el5-emacs-support.patch;hb=HEAD
³ http://pkgs.fedoraproject.org/gitweb/?p=git.git;a=blob;f=git-cvsimport-Ignore-cvsps-2.2b1-Branches-output.patch;hb=HEAD
⁴ https://bugzilla.redhat.com/490602
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dope will get you through times of no money better than money will get
you through times of no dope.
-- Freewheelin' Franklin
[-- Attachment #2: Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: "make quick-install-man" on git.git HEAD has failed for two days
From: Stefan Näwe @ 2011-11-10 16:33 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git@vger.kernel.org
In-Reply-To: <861utgymsv.fsf@red.stonehenge.com>
Am 10.11.2011 17:17, schrieb Randal L. Schwartz:
>
> Known issue? Should I have done something differently?
>
> "make install quick-install-man" ends with:
>
> make[2]: `GIT-VERSION-FILE' is up to date.
> git-manpages repository must exist at ../../git-manpages
> make[1]: *** [require-manrepo] Error 1
> make: *** [quick-install-man] Error 2
This should be fixed with fcbebfd "docs: Update install-doc-quick".
(It's in master)
You need to clone git-manpages.git next to git.git.
Stefan
--
----------------------------------------------------------------
/dev/random says: Useless Invention: Fireproof cigarettes.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: "make quick-install-man" on git.git HEAD has failed for two days
From: Stefan Näwe @ 2011-11-10 16:40 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git@vger.kernel.org
In-Reply-To: <4EBBFCD2.9060000@atlas-elektronik.com>
Am 10.11.2011 17:33, schrieb Stefan Näwe:
> Am 10.11.2011 17:17, schrieb Randal L. Schwartz:
>>
>> Known issue? Should I have done something differently?
>>
>> "make install quick-install-man" ends with:
>>
>> make[2]: `GIT-VERSION-FILE' is up to date.
>> git-manpages repository must exist at ../../git-manpages
>> make[1]: *** [require-manrepo] Error 1
>> make: *** [quick-install-man] Error 2
>
> This should be fixed with fcbebfd "docs: Update install-doc-quick".
> (It's in master)
>
> You need to clone git-manpages.git next to git.git.
FYI:
http://thread.gmane.org/gmane.comp.version-control.git/184930/focus=185084
Stefan
--
----------------------------------------------------------------
/dev/random says: Useless Invention: Fireproof cigarettes.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: "make quick-install-man" on git.git HEAD has failed for two days
From: Stefan Näwe @ 2011-11-10 16:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git@vger.kernel.org
In-Reply-To: <4EBBFCD2.9060000@atlas-elektronik.com>
Am 10.11.2011 17:33, schrieb Stefan Näwe:
> Am 10.11.2011 17:17, schrieb Randal L. Schwartz:
>>
>> Known issue? Should I have done something differently?
>>
>> "make install quick-install-man" ends with:
>>
>> make[2]: `GIT-VERSION-FILE' is up to date.
>> git-manpages repository must exist at ../../git-manpages
>> make[1]: *** [require-manrepo] Error 1
>> make: *** [quick-install-man] Error 2
>
> This should be fixed with fcbebfd "docs: Update install-doc-quick".
> (It's in master)
Errr...
"fcbebfd" is the cause, not the fix for it, of course.
> You need to clone git-manpages.git next to git.git.
Still true.
Stefan
--
----------------------------------------------------------------
/dev/random says: Time wounds all heels...
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: "make quick-install-man" on git.git HEAD has failed for two days
From: Randal L. Schwartz @ 2011-11-10 16:53 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org
In-Reply-To: <4EBBFCD2.9060000@atlas-elektronik.com>
>>>>> "Stefan" == Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
Stefan> You need to clone git-manpages.git next to git.git.
Thanks. New instructions, buried in a place I didn't read again. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-10 17:18 UTC (permalink / raw)
To: Johan Herland
Cc: Linus Torvalds, Ted Ts'o, Shawn Pearce, git, James Bottomley,
Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CALKQrgdxEXQGKQ3t9Sh82=U933ypHNg8duyVmG9uJbg2iST5fw@mail.gmail.com>
Johan Herland <johan@herland.net> writes:
> What about having one notes ref per branch? If/when the branch is merged,
> the associated notes ref containing the annotations for the commits on that
> branch would be merged as well (using "git notes merge").
That is a crude workaround that you could (with help from users) make it
work, but it does not change the fact that the current mechanism to
transfer and integrate notes across repositories is a bad match for what
the "signed commit" type annotations wants to achieve. In fact, the need
for such a workaround is an illustration of how bad a match the mechanism
is.
When you merge a history that has commit A into another history that did
not have that commit, the act of creating a merge commit itself should be
enough to make the resulting history to contain that commit. The commit
DAG already expresses it, and if a parallel "notes" mechanism needs to be
futzed with to match that DAG, and command like "merge" needs to be told
to help that process, that is a shortcoming of the "notes" mechanism.
^ permalink raw reply
* Re: RFH: unexpected reflog behavior with --since=
From: Eric Raible @ 2011-11-10 18:18 UTC (permalink / raw)
To: Miles Bader; +Cc: Jeff King, git@vger.kernel.org
In-Reply-To: <buok4785j8v.fsf@dhlpc061.dev.necel.com>
On 11/10/2011 3:06 AM, Miles Bader wrote:
> I think there's already confusion in this area, e.g., with @{...} using
> reflog dates, but "git log --since" using commit dates. This can be an
> easy trap to fall into because _often_ the two have similar granularity
> (when you're mostly pushing changes), but not _always_ (when you pull a
> big batch of changes).
>
> Soooo, being really really explicit about using reflog dates vs. commit
> dates -- and e.g., having option names like "--since" _always_ refer to
> commit dates -- would be a good thing, I think...
>
> -Miles
Surely you agree that my original example shows that the current behavior
is confusing, yes?
So you're advocating --reflog-since (or some such)?
Or to disable the early --since early exit when walking the reflog?
Or for something else?
- Eric
^ permalink raw reply
* Re: [PATCH 14/14] clone: give advice on how to resume a failed clone
From: Junio C Hamano @ 2011-11-10 21:21 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111110075654.GN27950@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We could make "git clone ..." automatically resume, but I'm a little
> nervous about that. I wrote a patch that did so, and it did work, but
> there are a lot of little hiccups as we violate the assumption that the
> directory didn't already exist (e.g., it writes multiple fetch refspec
> lines to the config).
Sorry, but I do not think the worry is quite justified.
The "assumption that directory didn't already exist" becomes an issue only
if you implement your "git clone" that automatically resumes as a thin
wrapper around the current "git clone" in the form of
until git clone ...
do
echo retrying...
done
Stepping back a bit, I think there are two different situations where
resumable clone is beneficial. The "git clone" process died either by the
machine crashing or the user hitting a \C-c, or the connection between the
server and the "git clone" got severed for some reason.
Right now, the "got disconnected" case results in "git clone" voluntarily
dying and as the result of this, the symptom appears the same. But it
does not have to be that way. If we know the underlying transport is
resumable, e.g. when you are fetching a prepared bundle over the wire.
I have this suspicion that in practice the "got disconnected" case is the
majority. If "git clone" does not die upon disconnect while fetching a
bundle, but instead the fetching of the bundle is resumed internally by
reconnecting to the server and requesting a range transfer, there is no
risk of "writes multiple fetch refspec lines" etc, no?
Of course, it is _also_ beneficial if we made "git clone" resumable after
you purposefully kill it (maybe you thought it will clone within minutes,
but it turns out that it may take hours and you have to turn off the
machine in the next five minutes before leaving the work, or something).
A solution for that case _could_ be used for the "got disconnected" case
by letting it voluntarily die as we currently do, but I do not think that
is an optimal solution to the "got disconnected" case.
^ 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