* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-20 17:38 UTC (permalink / raw)
To: spearce, 'Steffen Prohaska'; +Cc: 'git'
In-Reply-To: <20071019002451.GQ14735@spearce.org>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: den 19 oktober 2007 02:25
> To: Steffen Prohaska
> Cc: joakim.tjernlund@transmode.se; git
> Subject: Re: git push bug?
>
> Steffen Prohaska <prohaska@zib.de> wrote:
> > On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> > >
> > ># > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> ...
> > >error: refusing to create funny ref 'refs/linus' locally
> > >ng refs/linus funny refname
> > >error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> ...
> > You may need to cleanup though. I'm not sure if the remote side
> > already created 'refs/linus'. The error message only indicates that
> > locally git refused to create the "funny refname".
>
> Cute. The error message "error: refusing to create .. locally"
> is actually coming from the remote site. Locally here is
> actually remotely. We *really* should change that. Its l.169 of
> receive-pack.c, which is only running on the remote side. :)
>
> Anyone game to improve that error message? Should be a pretty
> simple patch. One of the may low-hanging fruits in Git.
Just gave it a try, using git sendmail. Hopefully it will
reach the list :)
^ permalink raw reply
* RE: [PATCH] Fix receive-pack error msg.
From: Joakim Tjernlund @ 2007-10-20 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <1192901822-20431-1-git-send-email-Joakim.Tjernlund@transmode.se>
ehh, git sendmail didn't send the whole commit msg, just the subject.
Trying again.
> -----Original Message-----
> From: Joackim Tjernlund [mailto:jocke@gentoo-jocke]
> Sent: den 20 oktober 2007 19:37
> To: git@vger.kernel.org
> Cc: Joakim Tjernlund
> Subject: [PATCH] Fix receive-pack error msg.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> receive-pack.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/receive-pack.c b/receive-pack.c
> index d3c422b..1521d0b 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -166,7 +166,7 @@ static const char *update(struct command *cmd)
> struct ref_lock *lock;
>
> if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> - error("refusing to create funny ref '%s'
> locally", name);
> + error("refusing to create funny ref '%s'
> remotely", name);
> return "funny refname";
> }
>
> --
> 1.5.3.4
>
>
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Steffen Prohaska @ 2007-10-20 18:04 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <20071020133359.GB19521@efreet.light.src>
On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>> git gui
>> =======
>>
>> git gui is a really nice program, and as I often said, I consider it
>> more porcelain than a gui, since it uses the git core directly,
>> instead
>> of wrapping around porcelain commands.
>>
>> The user experience I had with git gui made me think that this should
>> be the primary interface Windows users should be confronted with, not
>> the command line.
>>
>> The major problem we had in msysGit is that git-gui was to be
>> launched
>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>> the shell, where you usually start git gui in a working directory.
>
> It would be nice to install an entry in the explorer menu to run
> git-gui in
> a selected directory. It can be done by just writing something like
> to the
> registry (completely untested -- I just looked it up on the internet):
What you propose is already there!
Did you try the most recent setup?
http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
Steffen
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Jan Hudec @ 2007-10-20 18:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <A24982F6-40B2-4897-904E-99A135EC9D41@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Sat, Oct 20, 2007 at 20:04:20 +0200, Steffen Prohaska wrote:
>
> On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
>
>> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>>> git gui
>>> =======
>>>
>>> git gui is a really nice program, and as I often said, I consider it
>>> more porcelain than a gui, since it uses the git core directly, instead
>>> of wrapping around porcelain commands.
>>>
>>> The user experience I had with git gui made me think that this should
>>> be the primary interface Windows users should be confronted with, not
>>> the command line.
>>>
>>> The major problem we had in msysGit is that git-gui was to be launched
>>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>>> the shell, where you usually start git gui in a working directory.
>>
>> It would be nice to install an entry in the explorer menu to run git-gui
>> in
>> a selected directory. It can be done by just writing something like to the
>> registry (completely untested -- I just looked it up on the internet):
>
> What you propose is already there!
Nice. Thanks. Unfortunately I didn't yet have time to try out, and I didn't
see it mentioned.
> Did you try the most recent setup?
>
> http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
No; I don't have loosedows here (at home), so I'll have to try it at work
when I have a little time. I certainly will.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Johannes Sixt @ 2007-10-20 18:22 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <20071020025352.GA6569@spearce.org>
On Saturday 20 October 2007 04:53, Shawn O. Pearce wrote:
> > diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> > index 871b704..51d8a32 100644
> > --- a/builtin-fetch-pack.c
> > +++ b/builtin-fetch-pack.c
> > @@ -457,42 +457,37 @@ static int everything_local(struct ref **refs, int
> > nr_match, char **match) return retval;
> > }
> >
> > -static pid_t setup_sideband(int fd[2], int xd[2])
> > +static int sideband_demux(int fd, void *data)
> > {
> > - pid_t side_pid;
> > + int *xd = data;
> >
> > + close(xd[1]);
>
> If this is a threaded start_async() system this close is going
> to impact the caller.
Yes, I noticed this, too. I think that a solution calls for a member .in of
struct async analogous to .in of struct child_process.
How do we continue from here? Could you park the series in pu so that I don't
have to resend if it turns out that the fix is just another followup patch
(which is how I'd prefer to solve the issue)? Then I tell you no or go after
I have it tested on mingw.git.
-- Hannes
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Jan Hudec @ 2007-10-20 18:35 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce, pdmef
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:
> IIRC, I just cloned mutt's hg repo:
> hg clone http://dev.mutt.org/hg/mutt
> then imported it in git with the scripts at
> http://repo.or.cz/w/fast-export.git
> with
> hg-fast-export.sh -r ../mutt
> [...]
>
> Here is the culprit (or so I think). One of the guilty commits is:
>
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
>
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Judging from the symptoms, I would suspect hg-fast-export. Either mercurial
sometimes stores two same hashes instead of the hash and 0 (in which case
hg-fast-import should probably be ready to deal with it), or hg-fast-import
does something wrong when it sees the 0 parent.
> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.
>
> This explanation makes sense to me, now the problem is: have I messed
> up the import myself, the scripts/commands used are to blame, or is
> it entirely the original repo's fault?
>
> Since I've redone the import and the error remains, I guess
> that's not my fault :)
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Mark Levedahl @ 2007-10-20 18:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <18201.59649.800748.780690@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Shawn O. Pearce writes:
>
>
>> Yes, I admit this is an odd patch. I can certainly carry it in
>> my own tree (I already carry some other patches) but I wonder if
>> we shouldn't include it as some users may actually try to do this,
>> just like I did. Latest git-gui `master` already has changes to its
>> Makefile and shell startup boilerplate to handle this weird case.
>>
>
> Why do you need to change gitk itself? If you're going to modify it
> with sed, why can't you change the $0 on the 3rd line to the installed
> path of the gitk script?
>
>
While gitk is most likely installed as /usr/bin/gitk in Cygwin's
filespace, that could resolve to anything in the Windows file system. It
might be c:\cygwin\usr\bin\gitk, but could also be "d:\Documents and
Settings\Bill\Programs\cygwin\usr\bin\gitk" depending upon who installed
it and with what options. Both are seen as /usr/bin/gitk by Cygwin.
Thus, Shawn is correct in using cygpath to resolve the name.
Also, as Cygwin's tcl/tk package is bound to the port of the insight
debugger to Cygwin, and that project is stuck for years on 8.4.1, this
patch (or something like it) may be the only way to allow gitk to access
a more recent version on Cygwin in the foreseeable future. So, I think
this is a good idea.
Mark
^ permalink raw reply
* [PATCH] Mention split command in git-add manpage
From: Bram Schoenmakers @ 2007-10-20 19:15 UTC (permalink / raw)
To: git, gitster
Hello,
A little patch for the git-add manpage which mentions the 's' option for
splitting hunks in git-add -i mode.
---
Documentation/git-add.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 2fe7355..032957a 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -210,6 +210,7 @@ patch::
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+ s - split large hunks at context lines in the middle
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
--
1.5.2.5
Kind regards,
--
Bram Schoenmakers
You can contact me directly on ICQ with #153817629
^ permalink raw reply related
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Johannes Schindelin @ 2007-10-20 21:31 UTC (permalink / raw)
To: Scott R Parish; +Cc: git, spearce, gitster
In-Reply-To: <1192868006.v2.fusewebmail-240137@f>
Hi,
On Sat, 20 Oct 2007, Scott R Parish wrote:
> Wow, that sure cleaned up nicely! :)
Heh.
BTW I did not mean to discourage you... Rather, I wanted to show you that
this list is a wonderful place to learn, as I did, do, and will do many
times here. (Just to clarify, since somebody said that I am usually not
nice to newbies... cannot understand that at all ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Johannes Schindelin @ 2007-10-20 21:34 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Steffen Prohaska, Evan Carroll, git
In-Reply-To: <8e04b5820710200040q76301c58j33e5d0895956b150@mail.gmail.com>
Hi,
[please do not top post]
On Sat, 20 Oct 2007, Ciprian Dorin Craciun wrote:
> There is nothing wrong with either of the two approaches. They
> could both coexist but address different needs:
> -- the manual should be more oriented on technical issues and
> addresses only the most recent versions;
The problem: it is not just "the manual". It is the "user manual".
> -- the book should be more user-oriented, and more general,
> explaining how source management should be addressed by using git, and
> maybe make comparisons with may other versioning systems. Also the
> book could relate to many versions -- both old and new.
>
> Also I would note that the wiki book is more easy to edit... If
> you spot errors or want to add something you just go and edit it and
> the effect is immediate. But in contrast sending patches involves some
> overhead...
I am torn. On one side I like the Wiki approach. On the other hand, the
Wiki will get less review by git oldtimers, whereas the patches to
user-manual are usually reviewed as thoroughly as the code patches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jari Aalto @ 2007-10-20 22:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202126430.25221@racer.site>
* Sat 2007-10-20 Johannes Schindelin <Johannes.Schindelin@gmx.de> INBOX
> Hi,
>
> On Sat, 20 Oct 2007, Jari Aalto wrote:
>
>> - commented out call to list_common_cmds_help()
>
> If you're really sure that this is desired, do not comment it out. Delete
> it.
I'm sure.
There is no point of reminding *every* time you make a typo during
writing the commands. It fills half of the screen and obscures the
previous commands that were running. It's much more polite and elegant
in shorted form.
Jari
New patch follows.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* [PATCH] Fix diffcore-break total breakage
From: Linus Torvalds @ 2007-10-20 19:31 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Shawn O. Pearce
Ok, so on the kernel list, some people noticed that "git log --follow"
doesn't work too well with some files in the x86 merge, because a lot of
files got renamed in very special ways.
In particular, there was a pattern of doing single commits with renames
that looked basically like
- rename "filename.h" -> "filename_64.h"
- create new "filename.c" that includes "filename_32.h" or
"filename_64.h" depending on whether we're 32-bit or 64-bit.
which was preparatory for smushing the two trees together.
Now, there's two issues here:
- "filename.c" *remained*. Yes, it was a rename, but there was a new file
created with the old name in the same commit. This was important,
because we wanted each commit to compile properly, so that it was
bisectable, so splitting the rename into one commit and the "create
helper file" into another was *not* an option.
So we need to break associations where the contents change too much.
Fine. We have the -B flag for that. When we break things up, then the
rename detection will be able to figure out whether there are better
alternatives.
- "git log --follow" didn't with with -B.
Now, the second case was really simple: we use a different "diffopt"
structure for the rename detection than the basic one (which we use for
showing the diffs). So that second case is trivially fixed by a trivial
one-liner that just copies the break_opt values from the "real" diffopts
to the one used for rename following. So now "git log -B --follow" works
fine:
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
however, the end result does *not* work. Because our diffcore-break.c
logic is totally bogus!
In particular:
- it used to do
if (base_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
which basically says "don't bother to break small files". But that
"base_size" is the *smaller* of the two sizes, which means that if some
large file was rewritten into one that just includes another file, we
would look at the (small) result, and decide that it's smaller than the
break size, so it cannot be worth it to break it up! Even if the other
side was ten times bigger and looked *nothing* like the samell file!
That's clearly bogus. I replaced "base_size" with "max_size", so that
we compare the *bigger* of the filepair with the break size.
- It calculated a "merge_score", which was the score needed to merge it
back together if nothing else wanted it. But even if it was *so*
different that we would never want to merge it back, we wouldn't
consider it a break! That makes no sense. So I added
if (*merge_score_p > break_score)
return 1;
to make it clear that if we wouldn't want to merge it at the end, it
was *definitely* a break.
- It compared the whole "extent of damage", counting all inserts and
deletes, but it based this score on the "base_size", and generated the
damage score with
delta_size = src_removed + literal_added;
damage_score = delta_size * MAX_SCORE / base_size;
but that makes no sense either, since quite often, this will result in
a number that is *bigger* than MAX_SCORE! Why? Because base_size is
(again) the smaller of the two files we compare, and when you start out
from a small file and add a lot (or start out from a large file and
remove a lot), the base_size is going to be much smaller than the
damage!
Again, the fix was to replace "base_size" with "max_size", at which
point the damage actually becomes a sane percentage of the whole.
With these changes in place, not only does "git log -B --follow" work for
the case that triggered this in the first place, ie now
git log -B --follow arch/x86/kernel/vmlinux_64.lds.S
actually gives reasonable resulys. But I also wanted to verify it in
general, by doing a full-history
git log --stat -B -C
on my kernel tree with the old code and the new code.
There's some tweaking to be done, but generally, the new code generates
much better results wrt breaking up files (and then finding better rename
candidates). Here's a few examples of the "--stat" output:
- This:
include/asm-x86/Kbuild | 2 -
include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------
include/asm-x86/debugreg_32.h | 64 ---------------------------------
include/asm-x86/debugreg_64.h | 65 ---------------------------------
4 files changed, 68 insertions(+), 142 deletions(-)
Becomes:
include/asm-x86/Kbuild | 2 -
include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++-
include/asm-x86/debugreg_32.h | 64 -------------------------
3 files changed, 7 insertions(+), 68 deletions(-)
- This:
include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++--
include/asm-x86/bug_32.h | 37 -------------------------------------
include/asm-x86/bug_64.h | 34 ----------------------------------
3 files changed, 39 insertions(+), 73 deletions(-)
Becomes
include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++-----
include/asm-x86/bug_32.h | 37 -----------------------------------
2 files changed, 14 insertions(+), 43 deletions(-)
Now, in some other cases, it does actually turn a rename into a real
"delete+create" pair, and then the diff is usually bigger, so truth in
advertizing: it doesn't always generate a nicer diff. But for what -B was
meant for, I think this is a big improvement, and I suspect those cases
where it generates a bigger diff are tweakable.
So I think this diff fixes a real bug, but we might still want to tweak
the default values and perhaps the exact rules for when a break happens.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Hmm? At least the "should_break()" tests seem to make some amount of sense
now, I think.
Linus
----
diffcore-break.c | 11 +++++++----
tree-diff.c | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index ae8a7d0..c71a226 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -45,8 +45,8 @@ static int should_break(struct diff_filespec *src,
* The value we return is 1 if we want the pair to be broken,
* or 0 if we do not.
*/
- unsigned long delta_size, base_size, src_copied, literal_added,
- src_removed;
+ unsigned long delta_size, base_size, max_size;
+ unsigned long src_copied, literal_added, src_removed;
*merge_score_p = 0; /* assume no deletion --- "do not break"
* is the default.
@@ -63,7 +63,8 @@ static int should_break(struct diff_filespec *src,
return 0; /* error but caught downstream */
base_size = ((src->size < dst->size) ? src->size : dst->size);
- if (base_size < MINIMUM_BREAK_SIZE)
+ max_size = ((src->size > dst->size) ? src->size : dst->size);
+ if (max_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
if (diffcore_count_changes(src, dst,
@@ -89,12 +90,14 @@ static int should_break(struct diff_filespec *src,
* less than the minimum, after rename/copy runs.
*/
*merge_score_p = (int)(src_removed * MAX_SCORE / src->size);
+ if (*merge_score_p > break_score)
+ return 1;
/* Extent of damage, which counts both inserts and
* deletes.
*/
delta_size = src_removed + literal_added;
- if (delta_size * MAX_SCORE / base_size < break_score)
+ if (delta_size * MAX_SCORE / max_size < break_score)
return 0;
/* If you removed a lot without adding new material, that is
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
^ permalink raw reply related
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Shawn O. Pearce @ 2007-10-21 0:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200710202022.33782.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> wrote:
> On Saturday 20 October 2007 04:53, Shawn O. Pearce wrote:
> >
> > If this is a threaded start_async() system this close is going
> > to impact the caller.
>
> Yes, I noticed this, too. I think that a solution calls for a member .in of
> struct async analogous to .in of struct child_process.
Probably.
> How do we continue from here? Could you park the series in pu so that I don't
> have to resend if it turns out that the fix is just another followup patch
> (which is how I'd prefer to solve the issue)? Then I tell you no or go after
> I have it tested on mingw.git.
Yes, this series is already queued for pu. I built the branch last
night but didn't push anything out. I will be doing a push tonight
and this branch will be included in pu.
I think I would also rather receive a follow up patch than a
replacement/resend.
--
Shawn.
^ permalink raw reply
* [PATCH] Fix receive-pack error msg.
From: Joakim Tjernlund @ 2007-10-20 19:31 UTC (permalink / raw)
To: git; +Cc: Joakim Tjernlund
receive-pack is only executed remotely so when
reporting errors, say so.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
receive-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/receive-pack.c b/receive-pack.c
index d3c422b..1521d0b 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -166,7 +166,7 @@ static const char *update(struct command *cmd)
struct ref_lock *lock;
if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
- error("refusing to create funny ref '%s' locally", name);
+ error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Johannes Schindelin @ 2007-10-20 23:02 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <odetifoh.fsf@blue.sea.net>
Hi,
On Sun, 21 Oct 2007, Jari Aalto wrote:
> * Sat 2007-10-20 Johannes Schindelin <Johannes.Schindelin@gmx.de> INBOX
>
> > On Sat, 20 Oct 2007, Jari Aalto wrote:
> >
> >> - commented out call to list_common_cmds_help()
> >
> > If you're really sure that this is desired, do not comment it out. Delete
> > it.
>
> I'm sure.
Well, I'm almost sure of the opposite. One of the big results of the Git
Survey was that git is still not user-friendly enough. Your patch would
only make this issue worse.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (thePATH)
From: Johannes Schindelin @ 2007-10-20 20:25 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1192867937.v2.fusewebmail-240137@f>
Hi,
[please do not top post. Just delete everything you do not reply to, and
put your answers below the text you are replying to. This spares others
so much time.]
On Sat, 20 Oct 2007, Scott R Parish wrote:
> The theoretical drawback to this approach is that it could possibly
> effect the order in which the paths are tried. For instance, if a user
> did "export GIT_EXEC_PATH=", then the builtin_exec_path wouldn't be
> tried before the PATH. (i doubt that it would be a problem, but thought
> i should note it)
In that respect, my code does not change anything from your code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (thePATH)
From: Scott Parish @ 2007-10-20 20:57 UTC (permalink / raw)
To: Johannes Schindelin, git
In-Reply-To: <1192867937.v2.fusewebmail-240137@f>
Actually, i didn't test it right, execve() were using the files in
my cwd. In addition to you patch, you'd need to use execvp() instead
of execve().
sRp
On Sat, Oct 20, 2007 at 03:12:17AM -0500, Scott R Parish wrote:
> Yeah, that seems to work fine. The theoretical drawback to this approach
> is that it could possibly effect the order in which the paths are tried.
> For instance, if a user did "export GIT_EXEC_PATH=", then the
> builtin_exec_path wouldn't be tried before the PATH. (i doubt that it
> would be a problem, but thought i should note it)
>
> sRp
>
>
> ----- Original Message -----
> Subject: Re: [PATCH] When exec'ing sub-commands, fall back on execvp
> (thePATH)
> Date: Sat, October 20, 2007 0:30
> From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
>
> > Hi,
> >
> > On Fri, 19 Oct 2007, Scott Parish wrote:
> >
> > > diff --git a/exec_cmd.c b/exec_cmd.c
> > > index 9b74ed2..674c9f3 100644
> > > --- a/exec_cmd.c
> > > +++ b/exec_cmd.c
> > > @@ -34,15 +34,15 @@ int execv_git_cmd(const char **argv)
> > > {
> > > char git_command[PATH_MAX + 1];
> > > int i;
> > > + int rc;
> > > const char *paths[] = { current_exec_path,
> > > getenv(EXEC_PATH_ENVIRONMENT),
> > > builtin_exec_path };
> > > + const char *tmp;
> > > + size_t len;
> > >
> > > for (i = 0; i < ARRAY_SIZE(paths); ++i) {
> > > - size_t len;
> > > - int rc;
> > > const char *exec_dir = paths[i];
> > > - const char *tmp;
> > >
> > > if (!exec_dir || !*exec_dir) continue;
> > >
> > > @@ -106,8 +106,26 @@ int execv_git_cmd(const char **argv)
> > >
> > > argv[0] = tmp;
> > > }
> > > - return -1;
> > >
> > > + rc = snprintf(git_command, sizeof(git_command), "git-%s",
> argv[0]);
> > > + if (rc < 0 || rc >= sizeof(git_command) - len) {
> > > + fprintf(stderr, "git: command name given is too
> long.\n");
> > > + return -1;
> > > + }
> > > +
> > > + tmp = argv[0];
> > > + argv[0] = git_command;
> > > +
> > > + trace_argv_printf(argv, -1, "trace: exec:");
> > > +
> > > + /* execve() can only ever return if it fails */
> > > + execvp(git_command, (char **)argv);
> > > +
> > > + trace_printf("trace: exec failed: %s\n", strerror(errno));
> > > +
> > > + argv[0] = tmp;
> > > +
> > > + return -1;
> > > }
> >
> > I am not sure that this is elegant enough: Something like this (completely
> > untested) might be better:
> >
> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 9b74ed2..c928f37 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
> > int i;
> > const char *paths[] = { current_exec_path,
> > getenv(EXEC_PATH_ENVIRONMENT),
> > - builtin_exec_path };
> > + builtin_exec_path,
> > + "" };
> >
> > for (i = 0; i < ARRAY_SIZE(paths); ++i) {
> > size_t len;
> > @@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
> > const char *exec_dir = paths[i];
> > const char *tmp;
> >
> > - if (!exec_dir || !*exec_dir) continue;
> > + if (!exec_dir) continue;
> >
> > - if (*exec_dir != '/') {
> > + if (!*exec_dir)
> > + /* try PATH */
> > + *git_command = '\0';
> > + else if (*exec_dir != '/') {
> > if (!getcwd(git_command, sizeof(git_command))) {
> > fprintf(stderr, "git: cannot determine "
> > "current directory: %s\n",
> > @@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
> >
> > len = strlen(git_command);
> > rc = snprintf(git_command + len, sizeof(git_command) -
> len,
> > - "/git-%s", argv[0]);
> > + "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
> > if (rc < 0 || rc >= sizeof(git_command) - len) {
> > fprintf(stderr,
> > "git: command name given is too long.\n");
> >
> > Ciao,
> > Dscho
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Scott Parish @ 2007-10-20 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710202225520.25221@racer.site>
On Sat, Oct 20, 2007 at 10:31:47PM +0100, Johannes Schindelin wrote:
> BTW I did not mean to discourage you... Rather, I wanted to show you that
> this list is a wonderful place to learn, as I did, do, and will do many
> times here. (Just to clarify, since somebody said that I am usually not
> nice to newbies... cannot understand that at all ;-)
Nah, i'm actually rather encouraged that people have shown interest
in my patches and are so quick to find ways to improve on them!
Sorry about the top posting earlier; i've been away from active
open source participation for a while and have been forgetting my
etiquette.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Johannes Schindelin @ 2007-10-20 20:28 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <bqaujirk.fsf@blue.sea.net>
Hi,
On Sat, 20 Oct 2007, Jari Aalto wrote:
> - commented out call to list_common_cmds_help()
If you're really sure that this is desired, do not comment it out. Delete
it.
But am not at all sure that this is the way to go. Rather, I like it that
the most common commands are listed. It would be better to find out what
commands are really the most helpful to users who are likely to benefit
from the list, and to present them better (such as showing them in
categories).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Johannes Schindelin @ 2007-10-20 22:00 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071020205721.GA16291@srparish.net>
Earlier, we tried to find the git commands in several possible exec
dirs. Now, if all of these failed, try to find the git command in
PATH.
This allows you to install the git programs somewhere else than
originally specified when building git, as long as you add that location
to the PATH.
Initial implementation by Scott R Parish.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 20 Oct 2007, Scott Parish wrote:
> Actually, i didn't test it right, execve() were using the files
> in my cwd. In addition to you patch, you'd need to use execvp()
> instead of execve().
Ah, right. I missed that one ;-)
How about this instead?
exec_cmd.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c928f37 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
int i;
const char *paths[] = { current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
+ builtin_exec_path,
+ "" };
for (i = 0; i < ARRAY_SIZE(paths); ++i) {
size_t len;
@@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
const char *exec_dir = paths[i];
const char *tmp;
- if (!exec_dir || !*exec_dir) continue;
+ if (!exec_dir) continue;
- if (*exec_dir != '/') {
+ if (!*exec_dir)
+ /* try PATH */
+ *git_command = '\0';
+ else if (*exec_dir != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr, "git: cannot determine "
"current directory: %s\n",
@@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
len = strlen(git_command);
rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
+ "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
if (rc < 0 || rc >= sizeof(git_command) - len) {
fprintf(stderr,
"git: command name given is too long.\n");
--
1.5.3.4.1287.g8b31e
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Shawn O. Pearce @ 2007-10-21 2:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jari Aalto, git
In-Reply-To: <Pine.LNX.4.64.0710210001390.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Sat, 20 Oct 2007, Jari Aalto wrote:
> > >
> > >> - commented out call to list_common_cmds_help()
>
> Well, I'm almost sure of the opposite. One of the big results of the Git
> Survey was that git is still not user-friendly enough. Your patch would
> only make this issue worse.
Actually I think Jari's patch helps for the reason originally
stated in the message (less output when you make a small typo).
Though I agree that the commented out code should just be removed.
I actually had to do `git config alias.upsh push` just to keep
myself from screaming every time I made a small typo and Git gave
me a screenful of "helpful reminders".
Hmm. Lets see.
"cvs foo":
Big spew of commands. Like "git foo".
"svn foo":
Unknown command: 'foo'
Type 'svn help' for usage.
Both are considered to be more newbie friendly then Git. So clearly
SVN's output of almost nothing is friendly. And so is CVS'
big spew of frequently used commands. Either way is apparently
newbie friendly.
Though I find SVN's message a little insulting, asking me to type.
I know I have to type the command, thanks.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-20 23:06 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Andreas Ericsson, Federico Mena Quintero, Johannes Schindelin,
git
In-Reply-To: <DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de>
On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
> Maybe we could group commands into more categories?
>
> plumbing: should be hidden from the 'normal' user. Porcelain
> should be sufficient for every standard task.
The problem is division between what is porcelain and what is plumbing.
Some commands are right on border (git-fsck, git-update-index, git-rev-parse
comes to mind).
But it should be fairly easy to:
1. put only porcelain in bash / zsh completion ('git <tab>' shows
only porcelain
2. move plumbing out of PATH, but use exec-dir instead.
[...]
> mail porcelain: the list will probably hate me for this, but
> I think all commands needed to create and send patches per
> mail are not essential. I suspect that I'll _never_ ask
> my colleagues at work to send me a patch by mail. They'll
> always push it to a shared repo.
Usually mail porcelain is in separate binary package, git-mail for
RPMS packages for example. But iMVHO git-format-patch is as often used
as other commands, and is certainly porcelain.
> import/export: Many commands are only used for importing
> from or exporting to other version control systems. Examples
> are git-cvs*, git-svn*. They are not needed once you switched
> to git.
Those are also in separate packages.
> admin: Some commands are not used in a typical workflow. For
> example git-filter-branch or git-fsck have a more admin
> flavor.
These are a few commands only. I'm not sure about how to separate
those from ordinary commands.
[...]
> So here are a few questions:
>
> Could we find a small set of core porcelain commands that
> completely cover a typical workflow? The core section of the
> manual should only refer to those commands. Absolutely no
> plumbing should be needed to tweak things. In principle, a
> typical user should be able to work if _all other_ commands
> except for core porcelain are hidden from his PATH.
The problem here I suppose might lie with the same reason why
(almost?) all Office Lite systems failed: because even if 80% of people
use only 20% of functaionality, it is not the _same_ 20%.
--
Jakub Narebski
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-20 23:33 UTC (permalink / raw)
To: Jakub Narebski
Cc: Steffen Prohaska, Andreas Ericsson, Federico Mena Quintero, git
In-Reply-To: <8fe92b430710201606i47e85b24k17abd819bf0d353b@mail.gmail.com>
Hi,
On Sun, 21 Oct 2007, Jakub Narebski wrote:
> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> > Maybe we could group commands into more categories?
> >
> > plumbing: should be hidden from the 'normal' user. Porcelain
> > should be sufficient for every standard task.
>
> The problem is division between what is porcelain and what is plumbing.
> Some commands are right on border (git-fsck, git-update-index,
> git-rev-parse comes to mind).
Sorry, but my impression from the latest mails was that the commands are
fine. What is lacking is a nice, _small_ collection of recommended
workflows. And when we have agreed on such a set of workflows, we
optimize the hell out of them. Only this time it is not performance, but
user-friendliness.
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Shawn O. Pearce @ 2007-10-21 2:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, git
In-Reply-To: <Pine.LNX.4.64.0710202258440.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 20 Oct 2007, Scott Parish wrote:
>
> > Actually, i didn't test it right, execve() were using the files
> > in my cwd. In addition to you patch, you'd need to use execvp()
> > instead of execve().
>
> Ah, right. I missed that one ;-)
>
> How about this instead?
Uhhh. Its the same, isn't it? Still using execve() which means
we will not look at PATH in the final attempt.
> exec_cmd.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 9b74ed2..c928f37 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
> int i;
> const char *paths[] = { current_exec_path,
> getenv(EXEC_PATH_ENVIRONMENT),
> - builtin_exec_path };
> + builtin_exec_path,
> + "" };
>
> for (i = 0; i < ARRAY_SIZE(paths); ++i) {
> size_t len;
> @@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
> const char *exec_dir = paths[i];
> const char *tmp;
>
> - if (!exec_dir || !*exec_dir) continue;
> + if (!exec_dir) continue;
>
> - if (*exec_dir != '/') {
> + if (!*exec_dir)
> + /* try PATH */
> + *git_command = '\0';
> + else if (*exec_dir != '/') {
> if (!getcwd(git_command, sizeof(git_command))) {
> fprintf(stderr, "git: cannot determine "
> "current directory: %s\n",
> @@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
>
> len = strlen(git_command);
> rc = snprintf(git_command + len, sizeof(git_command) - len,
> - "/git-%s", argv[0]);
> + "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
> if (rc < 0 || rc >= sizeof(git_command) - len) {
> fprintf(stderr,
> "git: command name given is too long.\n");
> --
> 1.5.3.4.1287.g8b31e
--
Shawn.
^ permalink raw reply
* Re: [BUG] git-mv submodule failure
From: Johannes Schindelin @ 2007-10-20 21:24 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710192301p3e1d88d5l3b662b72b051d920@mail.gmail.com>
Hi,
On Sat, 20 Oct 2007, Yin Ping wrote:
> project
> .git
> file1
> submoudle
> .git
> file2
>
> $ cd project
> $ git-mv submodule submodule1
> fatal: source directory is empty, source=submodule, destination=submodule1
>
> However, the following is ok and rename is automatically detected
> $ cd project
> $ mv submodule submodule1
> $ git-add submodule1
> $ git-commit -a
>
> which gives in vim:
> # Please enter the commit message for your changes.
> # (Comment lines starting with '#' will not be included)
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # renamed: submodule -> submodule1
> #
But of course .gitmodules is unaffected. But it should be changed, too.
Ciao,
Dscho
^ 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