* Cannot push a commit
From: Matthias Fechner @ 2012-01-15 9:09 UTC (permalink / raw)
To: git
Dear List,
I have a big problem with a file which I cannot push to my central git
repository.
The file can be found here:
http://dl.fechner.net/APP_UD.sch
What I did to reproduce it:
On my server (freebsd with git 1.7.8.3)
cd
mkdir git-test
cd git-test
git init --bare
On my client a windows pc with tortoise git 1.7.6.0 and git 1.7.8.msysgit.0
I cloned the repository over ssh
Added a small test.txt file, commit and pushed it to the server,
everything is fine.
Then a copied the file above to the local repo, added it and commited it.
If I try to push it, I get the error message:
git.exe push --progress "origin" master:master
Counting objects: 4, done.
Compressing objects: 100% (3/3)
Writing objects: 100% (3/3), 80.00 KiB | 137 KiB/s
Writing objects: 100% (3/3), 91.63 KiB | 137 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
fatal: early EOF
error: unpack failed: unpack-objects abnormal exit
To idefix@fechner.net:git-test
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'idefix@fechner.net:git-test'
git config -l shows on the windows pc:
core.symlinks=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
user.name=Matthias Fechner
user.email=idefix@fechner.net
core.autocrlf=false
core.safecrlf=false
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=idefix@fechner.net:git-test
remote.origin.puttykeyfile=
branch.master.remote=origin
branch.master.merge=refs/heads/master
How can I solve this problem?
Is this maybe a bug in git?
Thanks a lot
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: [PATCH v3 1/3] Eliminate recursion in setting/clearing marks in commit list
From: Nguyen Thai Ngoc Duy @ 2012-01-15 9:25 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20120114152316.GA30986@m62s10.vlinux.de>
2012/1/14 Peter Baumann <waste.manager@gmx.de>:
> On Sat, Jan 14, 2012 at 07:19:53PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> Recursion in a DAG is generally a bad idea because it could be very
>> deep. Be defensive and avoid recursion in mark_parents_uninteresting()
>> and clear_commit_marks().
>>
>> mark_parents_uninteresting() learns a trick from clear_commit_marks()
>> to avoid malloc() in (dorminant) single-parent case.
> ^^^^^^^^^
>
> I think you ment dominant here.
Yes I meant dominant.
--
Duy
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-15 8:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Carlos Martín Nieto, git
In-Reply-To: <m3mx9re6t0.fsf@localhost.localdomain>
On 13.01.2012 20:34 CE(S)T, Jakub Narebski wrote:
>> Since I don't have access to the news system, I need to use the Gmane
>> website. I don't know exactly what it is.
>
> GMane is an e-mail to news gateway, and a mailing list archive. It
> exposes mailing list as a newsgroup, so it can be read and written to
> via newsreader (via Usenet).
I have Thunderbird, but I have no usenet server to entry in a usenet
account, so as I said, I don't have access to that part of the internet.
I had at university, but that's some time ago now.
> git@vger.kernel.org is a public non-subscribe mailing list; you don't
> need to subscribe to post requests there. Note that it is a custom on
> this mailing list to always include all participants in given
> (sub)thread directly in Cc, so you should get responses to your emails
> even if you are not subscribed.
Good to know NOW. It really should have informed me in the first place
on that website. It's a vital information without which you likely won't
get anywhere (as I).
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-15 8:14 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F1085EC.9010708@ira.uka.de>
On 13.01.2012 20:28 CE(S)T, Holger Hellmuth wrote:
> Is it possible that Visual Studio changes them while you are comitting?
No. Those files may only be modified while open.
>> I renamed the file and created a new one with the same name. Is it so
>> simple to crash the Git repository?
>
> Who said anything about crash? git simply doesn't care whether a change
> is because of a rename. It isn't special or different to any change you
> can make to a file
Well, there is a tracked file about which Git says it's untracked. How
would you describe such internal inconsistency? Maybe corruption would
fit better.
> As an aside, if .Designer.cs is generated automatically from Form1.cs it
> shouldn't be tracked at all.
Of course, it's important! The file contains everything I draw in the UI
designer. I just don't write that myself which is why I rarely see its
contents.
> Maybe tortoise git has a global gitignore
> with a line "*.Designer.cs" in it to account for that fact. Maybe this
> lead to the error message?
It hasn't. This is already triple-checked by now. The file really is
definitely not ignored by any of the both ignore/exclude files known to me.
>>> What does git diff -- Form1.Designer.cs' say?
>> Nothing.
>>
>>> What does 'git diff form-refactoring -- Form1.Designer.cs' say?
>> All lines deleted.
>
> Really all lines?
I don't have the time to re-check right now, but I remember seeing a
valid file beginning and end and no gaps in between. So I think it was
all files.
> That would indicate that you don't have a file
> Form1.Designer.cs (or an empty one) in your working directory in branch
> master. In case there is no file (as seen by git) the output of diff
> should compare with /dev/null aka the void aka <I don't know how this
> prints on the windows side>. Also notice the line "deleted file mode ..."
>
> > git diff master -- zumf
> diff --git a/zumf b/zumf
> deleted file mode 100644
> index 925eccd..0000000
> --- a/zumf
> +++ /dev/null
> @@ -1 +0,0 @@
>
> Or did you just mean "all the shown lines in the diff were fronted by a
> minus sign"?
Yes, and in dark red.
> Which would just indicate that the file in form-refactoring
> is a superset of the one in master.
>
> (As you can see, actual reproduction of command line output is very
> helpful to avoid ambiguity and can give further hints)
That was some kind of less display. I could have attached a screenshot
to show it. It's not common or especially simple to include console
output on Windows, as there often is no console at all.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: [PATCH v2 2/2] tree_entry_interesting: make recursive mode default
From: Junio C Hamano @ 2012-01-15 3:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Nieder, Linus Torvalds
In-Reply-To: <1326533003-19686-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This patch decouples the use of recursive field. The max_depth feature
> switch is now controlled by max_depth_valid field. diff-tree recursion
> is controlled by onelevel_only, which makes it recursive by default.
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 9ce064a..c081bf4 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -1051,7 +1051,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> paths = get_pathspec(prefix, argv + i);
> init_pathspec(&pathspec, paths);
> pathspec.max_depth = opt.max_depth;
> - pathspec.recursive = 1;
> + pathspec.max_depth_valid = 1;
We initialize opt.max_depth to "-1" (unlimited) and then let it be
overridden by the command line, and we set it to pathspec, so max_depth is
always valid, even when it is "-1", and is to be honoured.
> diff --git a/dir.c b/dir.c
> index 0a78d00..5af3567 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -258,7 +258,7 @@ int match_pathspec_depth(const struct pathspec *ps,
> int i, retval = 0;
>
> if (!ps->nr) {
> - if (!ps->recursive || ps->max_depth == -1)
> + if (!ps->max_depth_valid || ps->max_depth == -1)
> return MATCHED_RECURSIVELY;
> if (within_depth(name, namelen, 0, ps->max_depth))
When there is no pathspec given, if we do not have a valid depth limiter,
or a valid depth limiter says "-1" (unlimited), it is always a match.
Otherwise we have check the depth. Looks correct.
> @@ -275,7 +275,7 @@ int match_pathspec_depth(const struct pathspec *ps,
> if (seen && seen[i] == MATCHED_EXACTLY)
> continue;
> how = match_pathspec_item(ps->items+i, prefix, name, namelen);
> - if (ps->recursive && ps->max_depth != -1 &&
> + if (ps->max_depth_valid && ps->max_depth != -1 &&
> how && how != MATCHED_FNMATCH) {
> int len = ps->items[i].len;
> if (name[len] == '/')
Likewise. When there is a max_depth defined from the caller, and we did
not get the desired match, we check if we can go deeper to retry the
match. Looks correct.
These assume that tree-diff (the sole user of onelevel_only) never calls
into this function and ask to limit the recursion, though. Is it a good
thing for the longer-term code health?
In any case, both of the above seem to work without max_depth_valid. If
the caller does not want to use depth limiting, it can set max_depth to
"-1", and all the code after this patch that check ps->max_depth_valid can
pretend that max_depth_valid is set to 1, no?
> diff --git a/tree-diff.c b/tree-diff.c
> index 28ad6db..fbc683c 100644
> --- a/tree-diff.c
> +++ b/tree-diff.c
> @@ -137,8 +137,7 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2,
> enum interesting t2_match = entry_not_interesting;
>
> /* Enable recursion indefinitely */
> - opt->pathspec.recursive = DIFF_OPT_TST(opt, RECURSIVE);
> - opt->pathspec.max_depth = -1;
> + opt->pathspec.onelevel_only = !DIFF_OPT_TST(opt, RECURSIVE);
The comment "Enable recursion indefinitely" seems stale (not a problem
with this change).
> diff --git a/tree-walk.c b/tree-walk.c
> index 492c7cd..fdecacc 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -588,7 +588,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
> entry_not_interesting : all_entries_not_interesting;
>
> if (!ps->nr) {
> - if (!ps->recursive || ps->max_depth == -1)
> + if (!ps->max_depth_valid || ps->max_depth == -1)
> return all_entries_interesting;
> return within_depth(base->buf + base_offset, baselen,
> !!S_ISDIR(entry->mode),
When there is no pathspec given, if we do not have a valid depth limiter
(i.e. caller is diff-tree), or a valid depth limiter says "-1" (unlimited),
everything in this tree is interesting. If we have depth limit, we need to
check it.
But how would onelevel_only option interact with this codepath? We used to
have recursive == false and max_depth == -1 in a non-recursive diff-tree,
so the old code would have returned all_entries_interesting. Now we rely
on max_depth_valid being invalid. Again, wouldn't this work without
max_depth_valid if max_depth is set to "-1" in diff-tree?
> @@ -609,7 +609,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
> if (!match_dir_prefix(base_str, match, matchlen))
> goto match_wildcards;
>
> - if (!ps->recursive || ps->max_depth == -1)
> + if (!ps->max_depth_valid || ps->max_depth == -1)
> return all_entries_interesting;
> return within_depth(base_str + matchlen + 1,
Likewise. Everything is interesting in a matched entry, when not
depth-limited. Otherwise we would need to check the depth. Looks correct.
Again, how would onelevel_only option interact with this part?
> @@ -634,7 +634,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
> * Match all directories. We'll try to
> * match files later on.
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (!ps->onelevel_only && S_ISDIR(entry->mode))
> return entry_interesting;
> }
>
> @@ -665,7 +665,7 @@ match_wildcards:
> * in future, see
> * http://thread.gmane.org/gmane.comp.version-control.git/163757/focus=163840
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (!ps->onelevel_only && S_ISDIR(entry->mode))
> return entry_interesting;
> }
> return never_interesting; /* No matches */
Before we had recursive and max_depth. Now you have three instead of two.
The only thing we are trying to say with these three is if we want to
allow unlimited recursion, no recursion or recursion limited to a certain
depth. An integer option ought to work, and various codepaths that used to
look at the old two variables are converted to look at only just a few of
the new three variables, and never all three of them.
That makes my head hurt and makes me suspect there is something
fundamentally wrong in the patch. Sigh...
^ permalink raw reply
* Re: [PATCH v2 1/2] Document limited recursion pathspec matching with wildcards
From: Junio C Hamano @ 2012-01-15 2:38 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jonathan Nieder, Linus Torvalds
In-Reply-To: <1326533003-19686-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> It's actually unlimited recursion if wildcards are active regardless
> --max-depth
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Regarding Junio's question earlier:
>
> > - Shouldn't "onelevel_only" be the same as limiting to a single depth
> > with "max_depth"?
>
> Doing that would change the behavior of "git grep --max-depth=0 -- 'a*'"
> from unlimited recursion currently to limited. We did not come to agree
> how --max-depth should behave with wildcards last time it was discussed,
> so it's best separating two flags (in the next patch) for now.
Ok, I 100% agree with the "at least for now" reasoning. Thanks for digging
into the archive.
> Documentation/git-grep.txt | 3 +++
> tree-walk.c | 3 +++
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> index 15d6711..6a8b1e3 100644
> --- a/Documentation/git-grep.txt
> +++ b/Documentation/git-grep.txt
> @@ -79,6 +79,9 @@ OPTIONS
> --max-depth <depth>::
> For each <pathspec> given on command line, descend at most <depth>
> levels of directories. A negative value means no limit.
> + This option is ignored if <pathspec> contains active wildcards.
> + In other words if "a*" matches a directory named "a*",
> + "*" is matched literally so --max-depth is still effective.
Do we have a definition of "active wildcard"?
> diff --git a/tree-walk.c b/tree-walk.c
> index f82dba6..492c7cd 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -661,6 +661,9 @@ match_wildcards:
> /*
> * Match all directories. We'll try to match files
> * later on.
> + * max_depth is ignored but we may consider support it
> + * in future, see
> + * http://thread.gmane.org/gmane.comp.version-control.git/163757/focus=163840
> */
> if (ps->recursive && S_ISDIR(entry->mode))
> return entry_interesting;
^ permalink raw reply
* Re: [PATCH v4 00/10] nd/clone-detached
From: Junio C Hamano @ 2012-01-15 2:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <20120114074036.GA27256@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> Hmm, 'pu' seems to fail its selftest with this merge present, though.
>
> The commit "refuse to clone if --branch points to bogus ref" from this
> series changes clone's behavior that t5500.31, which is added in
> nd/clone-single-branch, relies on.
Ahh, of course.
> Another cleaner approach is to combine the two clone series into
> one.
I think "--single-branch" is much more relevant compared to cloning from a
repository with some funkiness like detached HEAD which is more about a
theoretical fun exercise, so let's rebuild this on top of the other one.
Thanks.
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Junio C Hamano @ 2012-01-15 2:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFzRN2F5PZDZPRmbj9occZwA6E6Pi+S+M_Qq2EfS6sctyA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Just a heads-up and congrats: octopus merges of signed tags work well,
> and did exactly the RightThing(tm), both at merge time and with
> "--show-signature".
Heh, thanks.
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-15 2:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1326567336-2173-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b0062ba..488e1f4 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -534,6 +534,12 @@ __gitcomp_nl ()
> fi
> fi
>
> + # ZSH would quote the trailing space added with -S. bash users
> + # will appreciate the extra space to compensate the use of -o nospace.
> + if [ -n "${ZSH_VERSION-}" ] && [ "$suffix" = " " ]; then
> + suffix=""
> + fi
This should take care of the SP set by the beginning of the helper
function
local cur_="$cur" suffix=" "
but is that the right thing to do if suffix came from "$4"?
As far as I can see, "$4" is used to append "." in very limited cases, and
nobody explicitly passes SP as "$4" when calling this, so it may be easier
to read if you moved this before that "if we have 3 or more args, use the
fourth one as the suffix" block, i.e. something like this?
contrib/completion/git-completion.bash | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b0062ba..4ad75ed 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -525,7 +525,10 @@ __gitcomp ()
__gitcomp_nl ()
{
local s=$'\n' IFS=' '$'\t'$'\n'
- local cur_="$cur" suffix=" "
+ local cur_="$cur"
+ # Because we use '-o nospace' under bash, we need to compensate
+ # for it by appending SP after completed word ourselves.
+ local suffix="${BASH_VERSION+ }"
if [ $# -gt 2 ]; then
cur_="$3"
^ permalink raw reply related
* Re: Sending patches with KMail
From: Junio C Hamano @ 2012-01-15 2:14 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Rüdiger Sonderfeld, git, davidk, Sergei Organov, Kevin Ryde,
Michele Ballabio
In-Reply-To: <20120114183111.GC27850@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> My favorite approach would be to introduce a new option
> --format=plain|mbox, with the default being mbox, allowing format-patch
> --format=plain to produce a nice patch that does _not_ include a "From "
> line or q-encode its header lines, ready for use without much tweaking
> in an email body as an attachment.
I actually like the removal of q-encoding part. But I am not sure what
headers it should produce. What should the beginning of the output file
look like? Does it just have "Subject: ", or does it still have the "From:
", "Date: " and "Subject: ", the first two of which the user would almost
always want to remove?
If we can decide a sane behaviour wrt the pseudo header, and if the option
is made _incompatible_ with --stdout when (and only when) emitting more
than one message, then I think it would be a good addition.
^ permalink raw reply
* Re: git grep doesn't follow symbolic link
From: Junio C Hamano @ 2012-01-15 2:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Pang Yan Han, Thomas Rast, Ramkumar Ramachandra, Bertrand BENOIT,
git
In-Reply-To: <CACsJy8BfvhWxqBOj=+7AiF8dZBVEASAuxiOsjOvpmfE3uPrO3A@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> Even though some platforms may lack symbolic links, where they are
>> supported, they have a clear and defined meaning and that is what Git
>> tracks as contents: where the link points at.
>>
>> So we would want our "git diff" to tell us, even if you moved without
>> content modification the symbolic link target that lives somewhere on your
>> filesystem but is outside the control of Git, and updated a symbolic link
>> that is tracked by Git to point to a new location, that you updated the
>> link. On the other hand, if you did not update a tracked symbolic link,
>> even if the location the link points at that may or may not be under the
>> control of Git, we do not want "git diff" to show anything. As far as that
>> link is concerned, nothing has changed.
>>
>> Changing this would not be a fix; it would be butchering.
>
> That's a good default. But git should allow me to say "diff the files
> that symlinks point to". Link target is content from git perspective,
> not from user perspective.
>
> So instead changing the default behavior specifically for git-grep as
> Pang did, I think adding --follow-symlinks option, that could be
> passed to grep or any of diff family, would be a better approach.
Stop and think what "git diff --follow-symlinks v1.3.0 v1.7.0" should do
when these versions record a symbolic link, "from user perspective", if
the link points outside the tracked contents. Naturally, the users would
expect that the comparison is made between the contents of the file back
when v1.3.0 was tagged and the contents of the file (which may or may not
be the same path depending on the target of that symbolic link) back when
v1.7.0 was tagged.
But that is something that the user is *NOT* tracking with the system, and
hence something we cannot give the right answer. Your "--follow-symlinks"
option only encourages the *wrong* perception on the users' side, without
supporting what it appears to promise to the users. Why could it be an
improvement?
Compared to that, limiting the optional support for following symlinks
only in "--no-index" case, where the user explicitly asks us to look at
the data that is not managed by Git at all, makes more sense. At the
design level, I wouldn't be fundamentally opposed to a change to add an
optional "follow the symlink" feature only when "--no-index" is asked for.
I didn't look at the posted patch, so I do not know if it adds an optional
following or unconditionally makes us follow symbolic links, or if the
patch sensibly implements the feature, though. That is a separate issue.
^ permalink raw reply
* Re: Zsh completion regression
From: Stefan Haller @ 2012-01-14 21:36 UTC (permalink / raw)
To: SZEDER Gábor, Matthieu Moy; +Cc: git
In-Reply-To: <20120114132343.GW30469@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> wrote:
> However.
>
> While playing around with zsh, I noticed that git completion works
> without even sourcing git's bash completion script. As it turned out,
> zsh ships its own git completion script[1], and from my cursory tests
> it seems to be quite capable: it supports commands, aliases, options,
> refs, ref1..ref2, config variables, ... and I also saw a __git_ps1()
> equivalent for zsh.
>
> So, is there any reason why you are still using git's bash completion
> under zsh (which has some quirks and lacks some features) instead of
> zsh's own? Perhaps it would make sense to point zsh users to zsh's
> git completion and drop zsh compatibility from git's bash completion.
> We did similar with vim config files: git included a vim syntax
> highlight config file for commit messages under contrib/vim/, but
> eventually we dropped it after vim started shipping more capable
> git-specific config files (for git config files, rebase instruction
> sheets, etc.).
Last time I compared the two, the bash completion script was a lot more
complete and powerful. The zsh script had a few annoying limitations for
things that I use every day, and that worked with the bash script, so I
switched to that. Unfortunately I forgot the details, it's a while ago.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: Zsh completion regression
From: Stefan Haller @ 2012-01-14 21:36 UTC (permalink / raw)
To: SZEDER Gábor, Matthieu Moy; +Cc: git
In-Reply-To: <20120114152030.GX30469@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> wrote:
> I can imagine that it's irritating, that's why I aimed for
> this minimal regression fix, which, maybe with a Tested-by from you or
> Stefan, can even go into maint, so affected users can get it faster.
The patch works well for me, so feel free to add a Tested-by from me.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Signed tags in octopus merge..
From: Linus Torvalds @ 2012-01-14 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Just a heads-up and congrats: octopus merges of signed tags work well,
and did exactly the RightThing(tm), both at merge time and with
"--show-signature".
I knew it was supposed to work, but I have to admit that I was a bit
apprehensive about it when I tried.
Current top-of-head (commit 81d48f0aee54) in the kernel, in case you care.
Good job,
Linus
^ permalink raw reply
* The shared Git repo used by git-new-workdir
From: Hilco Wijbenga @ 2012-01-14 20:59 UTC (permalink / raw)
To: Git Users
Hi all,
First off, I use git-new-workdir a lot and it's working great. Kudos
to its developers!
I have been looking at the Git clone that is at the root of
git-new-workdir (i.e. the repository that is reused by all my
git-new-workdir created directories). This repo shows a lot of
activity when I run "git status" there.
So now I'm wondering. Should I simply ignore this completely? Or is
there some "clean up" I can do so that "git status" shows nothing? Or
would I destroy my git-new-workdir directories doing that? So far I've
only used this repo to create branches (i.e. to run git-new-workdir).
I would like to understand a bit better how I should treat this repo.
Whether it's basically a "do-not-touch" environment or whether I can
safely treat it as a normal Git repo.
Cheers,
Hilco
^ permalink raw reply
* Re: git-upload-archive help was not shown correctly
From: Jeff King @ 2012-01-14 20:56 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: devendra, git
In-Reply-To: <20120114154633.GA3444@beez.lab.cmartin.tk>
On Sat, Jan 14, 2012 at 04:46:33PM +0100, Carlos Martín Nieto wrote:
> On Sat, Jan 14, 2012 at 07:10:16PM +0530, devendra wrote:
> > Hi git folks,
> >
> > the command git-upload-archive is not properly showing usage info when
> > ran barely with out any args.
>
> git-upload-package is not for human use. It's what gets run on the
> remote end when you run e.g. 'git archive --remote=origin HEAD'
Yeah, but notice that it does detect the error condition; it just wraps
it in a bunch of cruft. More explanation (and a patch) are below, though
I'm lukewarm on the patch.
> > it shows some kind of unwanted garbage instead of showing a nice help
> > message.
>
> It's trying to talk to git. What you see is the "Git Smart
> Protocol". What were you trying to do?
Yeah, this is the more important question. You shouldn't generally ever
be running git-upload-* yourself.
-- >8 --
Subject: upload-archive: detect bad command-line arguments early
The upload-archive command spawns a helper process to
actually generate the archive (passing along all of its
command-line arguments), and the parent process then
multiplexes the stdout and stderr of the helper back to the
client.
This means an incorrect invocation (which in this case means
failing to provide a single <repo> argument) will cause the
helper to complain, and the error will be sent to the client
over the multiplexed channel.
This is not ideal for two reasons:
1. An invocation error in upload-pack is almost certainly
not something the client can do anything about. It
generally implies a bug in either git-daemon or
git-archive. The one exception is something like:
git archive --remote=ssh_host:repo.git \
--exec="git upload-archive bogus" \
2. For local users who are experimenting with git
commands, running "upload-archive" appears to generate
a bunch of barely-readable garbage (which is in fact
the git protocol intermingled with stderr). It's nicer
if we provide them with a readable error message.
Instead, we can detect a bad command-line before we spawn
the helper and give a more human-readable complaint (i.e.,
helping reason (2) above). This doesn't hurt case (1) as
much as you might think, because in the ssh case, the user
should be receiving stderr from the parent process anyway.
So before they saw:
$ git archive --remote=... --exec='git upload-archive bogus'
fatal: sent error to the client: git upload-archive: archiver died with error
remote: usage: git upload-archive <repo>
remote: git upload-archive: archiver died with error
and now they see:
usage: git upload-archive <repo>
fatal: The remote end hung up unexpectedly
Signed-off-by: Jeff King <peff@peff.net>
---
I'm lukewarm on this patch. I actually think the original output is
slightly nicer, so you are hurting case (1) for people in case (2). But
case (2), running random programs to see what happens, is not something
we probably need to be encouraging.
builtin/upload-archive.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin/upload-archive.c b/builtin/upload-archive.c
index b928beb..0733775 100644
--- a/builtin/upload-archive.c
+++ b/builtin/upload-archive.c
@@ -10,6 +10,8 @@
static const char upload_archive_usage[] =
"git upload-archive <repo>";
+static const char upload_archive_writer_usage[] =
+ "git upload-archive--writer <repo>";
static const char deadchild[] =
"git upload-archive: archiver died with error";
@@ -25,7 +27,7 @@ int cmd_upload_archive_writer(int argc, const char **argv, const char *prefix)
int len;
if (argc != 2)
- usage(upload_archive_usage);
+ usage(upload_archive_writer_usage);
if (strlen(argv[1]) + 1 > sizeof(buf))
die("insanely long repository name");
@@ -96,6 +98,9 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
{
struct child_process writer = { argv };
+ if (argc != 2)
+ usage(upload_archive_usage);
+
/*
* Set up sideband subprocess.
*
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
* Re: Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.)
From: Rüdiger Sonderfeld @ 2012-01-14 19:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, davidk, Sergei Organov, Kevin Ryde,
Michele Ballabio
In-Reply-To: <7vlipbxfne.fsf@alter.siamese.dyndns.org>
On Friday 13 January 2012 16:59:49 Junio C Hamano wrote:
> Perhaps rephrasing the early part of the Discussion section, with an
> illustration that is designed to be more visible, would be a better
> approach?
Why not do both?
I think you are right, that it is currently not very visible in the Discussion
section. But on the other hand if you have a step by step guide it should
probably mention that as well. It has nothing to do with laziness. But most
people follow a step by step guide because they expect that it illustrates the
correct procedure. Jonathan's addition is short but effective.
Regards,
Rüdiger
^ permalink raw reply
* [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Matthieu Moy @ 2012-01-14 18:55 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <20120114152030.GX30469@goldbirke>
Commit a31e626 (completion: optimize refs completion) introduced a
regression for ZSH users: ref names were completed with a quoted trailing
space (i.e. "git checkout ma" completes to "git checkout master\ "). The
space is convenient for bash users since we use "-o nospace", but a
quoted space is worse than nothing. The absence of trailing space for ZSH
is a long-standing issue, that this patch is not fixing. We just fix the
regression by not appending a space when the shell is ZSH.
Original-patch-by: SZEDER Gábor <szeder@ira.uka.de>
Reported-by: Stefan Haller <lists@haller-berlin.de>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/completion/git-completion.bash | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b0062ba..488e1f4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -534,6 +534,12 @@ __gitcomp_nl ()
fi
fi
+ # ZSH would quote the trailing space added with -S. bash users
+ # will appreciate the extra space to compensate the use of -o nospace.
+ if [ -n "${ZSH_VERSION-}" ] && [ "$suffix" = " " ]; then
+ suffix=""
+ fi
+
IFS=$s
COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
}
--
1.7.9.rc0.25.gb9a1f.dirty
^ permalink raw reply related
* Re: Sending patches with KMail
From: Jonathan Nieder @ 2012-01-14 18:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Rüdiger Sonderfeld, git, davidk, Sergei Organov, Kevin Ryde,
Michele Ballabio
In-Reply-To: <20120114183111.GC27850@burratino>
Jonathan Nieder wrote:
> My favorite approach would be to introduce a new option
> --format=plain|mbox, with the default being mbox, allowing
> format-patch --format=plain to produce a nice patch that does _not_
> include a "From " line or q-encode its header lines, ready for use
> without much tweaking in an email body as an attachment.
This should have said "ready for use in an email body or as an
attachment" (missing "or"). Sorry for the confusion.
^ permalink raw reply
* Re: Sending patches with KMail
From: Jonathan Nieder @ 2012-01-14 18:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Rüdiger Sonderfeld, git, davidk, Sergei Organov, Kevin Ryde,
Michele Ballabio
In-Reply-To: <7vlipbxfne.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> The hints at [1] might also be useful, in case you would like to try
>> and consider improving the manpage to document them if they work.
>
> Don't you need similar updates to sections for other MUAs and procedures?
Thunderbird approach 3, yes[*]. The others, no.
[...]
> Perhaps rephrasing the early part of the Discussion section, with an
> illustration that is designed to be more visible, would be a better
> approach?
I understand what you mean, but I don't think so. The Discussion
section already seems clear to me, so I would prefer to wait to hear
from someone confused by it to find what exactly in it needs tweaking.
Adding additional paragraphs for each potential misunderstanding by
people who have not necessarily read the section has the potential to
backfire and lead even more people not to read the section...
My favorite approach would be to introduce a new option
--format=plain|mbox, with the default being mbox, allowing
format-patch --format=plain to produce a nice patch that does _not_
include a "From " line or q-encode its header lines, ready for use
without much tweaking in an email body as an attachment. Then we can
just say "If you are not importing your patch as an mbox file, use the
--format=plain option".
Sane?
Jonathan
[*] Though I'd rather just remove it, since "how to use an external
editor" seems orthogonal to "how to teach Thunderbird not to mangle my
patches".
^ permalink raw reply
* Re: git-upload-archive help was not shown correctly
From: Carlos Martín Nieto @ 2012-01-14 15:46 UTC (permalink / raw)
To: devendra; +Cc: git
In-Reply-To: <1326548416.5992.1.camel@devendra-Linux>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On Sat, Jan 14, 2012 at 07:10:16PM +0530, devendra wrote:
> Hi git folks,
>
> the command git-upload-archive is not properly showing usage info when
> ran barely with out any args.
git-upload-package is not for human use. It's what gets run on the
remote end when you run e.g. 'git archive --remote=origin HEAD'
>
> it shows some kind of unwanted garbage instead of showing a nice help
> message.
It's trying to talk to git. What you see is the "Git Smart
Protocol". What were you trying to do?
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] Eliminate recursion in setting/clearing marks in commit list
From: Peter Baumann @ 2012-01-14 15:23 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1326543595-28300-2-git-send-email-pclouds@gmail.com>
On Sat, Jan 14, 2012 at 07:19:53PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Recursion in a DAG is generally a bad idea because it could be very
> deep. Be defensive and avoid recursion in mark_parents_uninteresting()
> and clear_commit_marks().
>
> mark_parents_uninteresting() learns a trick from clear_commit_marks()
> to avoid malloc() in (dorminant) single-parent case.
^^^^^^^^^
I think you ment dominant here.
^ permalink raw reply
* Re: Zsh completion regression
From: SZEDER Gábor @ 2012-01-14 15:20 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Stefan Haller, git
In-Reply-To: <vpq7h0ufj87.fsf@bauges.imag.fr>
Hi,
On Sat, Jan 14, 2012 at 03:32:08PM +0100, Matthieu Moy wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
> > We could fix the regression by not appending a space suffix to
> > completion words in __gitcomp_nl(), but only when the completion
> > script is running under zsh to avoid hurting bash users, like this:
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 2d02a7f3..49393243 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -601,6 +601,9 @@ __gitcomp_nl ()
> > suffix="$4"
> > fi
> > fi
> > + if [ -n "${ZSH_VERSION-}" ] && [ "$suffix" = " " ]; then
> > + suffix=""
> > + fi
> >
> > IFS=$s
> > COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
>
> I hate to see special case for different shells,
I agree and thought about that, too. We are dealing with zsh quirks
in the completion script either by
- having whole functions with different definitions in zsh and
in bash (currently__git_shopt() and _get_comp_words_by_ref()), or
- having similar shell-specific cases inside functions (currently
_git() and _gitk()).
We use the former when the implementations for the two shells differ
significantly, and the latter when the shell-specific parts are small
and most of the function's implementation can be used in both shells.
I think this regression fix fits into the latter category.
> but if no one finds a
> better solution, then yes, this is the way to go. Not having the space
> may be irritating, but having the quoted space hurts really much more (I
> have to delete the space and the backslash manually to continue).
I have no better idea for fixing this regression, and no idea at all
for a proper fix (i.e. to make zsh behave the same way in this respect
as bash). I can imagine that it's irritating, that's why I aimed for
this minimal regression fix, which, maybe with a Tested-by from you or
Stefan, can even go into maint, so affected users can get it faster.
Best,
Gábor
^ permalink raw reply
* Re: Zsh completion regression
From: Matthieu Moy @ 2012-01-14 14:32 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Stefan Haller, git
In-Reply-To: <20120114132343.GW30469@goldbirke>
SZEDER Gábor <szeder@ira.uka.de> writes:
>> but e.g. "git checkout
>> master<TAB>" does not add the trailing space, at all.
>
> I'm not sure what you mean; did you got a trailing space after
> 'master<TAB>' before a31e6262 (completion: optimize refs completion,
> 2011-10-15)?
No. My above sentence should read "... not add the trailing space, at
all, even for bash users". IOW, your understanding is correct.
> We could fix the regression by not appending a space suffix to
> completion words in __gitcomp_nl(), but only when the completion
> script is running under zsh to avoid hurting bash users, like this:
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 2d02a7f3..49393243 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -601,6 +601,9 @@ __gitcomp_nl ()
> suffix="$4"
> fi
> fi
> + if [ -n "${ZSH_VERSION-}" ] && [ "$suffix" = " " ]; then
> + suffix=""
> + fi
>
> IFS=$s
> COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
I hate to see special case for different shells, but if no one finds a
better solution, then yes, this is the way to go. Not having the space
may be irritating, but having the quoted space hurts really much more (I
have to delete the space and the backslash manually to continue).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Commit changes to remote repository
From: Matthieu Moy @ 2012-01-14 14:27 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: ruperty, git
In-Reply-To: <20120114113141.GG2850@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> You're trying to push to a non-bare repository and change the
> currently active branch, which can cause problems, so git isn't
> letting you. There's an explanation of bare and non-bare at
> http://bare-vs-nonbare.gitrecipes.de/ but the short and sweet is that
> you should init the repo you want to use as the central point with
> --bare and do modifications locally and then push there.
An alternative is to push to a temporary, non-checked-out branch.
I sometimes do
laptop$ git push desktop HEAD:incomming
and then
desktop$ git merge incomming
The push does not disturb the worktree on the desktop, and the merge is
done manually on the receiving machine.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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