* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (the PATH)
From: Johannes Schindelin @ 2007-10-20 7:30 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071020064459.GB2237@srparish.net>
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
^ permalink raw reply related
* Re: Announcement of Git wikibook
From: Ciprian Dorin Craciun @ 2007-10-20 7:40 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Evan Carroll, git
In-Reply-To: <C0D5CAE0-A152-4572-81D5-AF2A78DD89C6@zib.de>
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 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...
Ciprian.
On 10/19/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Oct 19, 2007, at 10:21 PM, Evan Carroll wrote:
>
> > I've create a git wikibook if anyone wants to help expand it.
> > http://en.wikibooks.org/wiki/Source_Control_Management_With_Git
>
> I'm just curious. What is the advantage of a wikibook?
>
> We already have a manual
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
>
> including a todo list
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#todo
>
> So, why don't you send patches improving the manual, but instead
> started a wiki book from scratch?
>
> Steffen
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Mike Hommey @ 2007-10-20 7:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ari Entlich, git
In-Reply-To: <20071020063014.GU14735@spearce.org>
On Sat, Oct 20, 2007 at 02:30:14AM -0400, Shawn O. Pearce wrote:
> Ari Entlich <lmage11@twcny.rr.com> wrote:
> > On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:
> > > --index is used in Git for places were we update *both* the index
> > > and the working directory (git-apply --index). So actually I should
> > > have suggested "git-mv --index". Whoops.
> >
> > Alright then, I don't know about that particular convention. If this
> > behavior can't be made default, git mv --index should activate it? I
> > there anything else that might be more descriptive?
>
> That's always the hard part. I actually think the current behavior
> should be called --index as it does not only the working tree
> update but also stages the whole file into the index, which is what
> git-apply --index does.
>
> What about just -u for "keep unstaged"?
Why not --staged ? It would be more meaningful than the --cached in some
other commands.
Mike
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-20 8:03 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <1192827476.4522.93.camel@cacharro.xalalinux.org>
Federico Mena Quintero wrote:
>
> "Find out why people find git hard to learn and eliminate those barriers
> to entry" is what we do with usability tests e.g. in GNOME.
And what every major corporation who's serious about UI's do. Windows
works the way it does because that's how idiots expect it to work. Sad but
true. If our aim is world domination, we need not cater to the morons, but
we must make it easier for them to start learning on their own.
> You ask
> people to use your software to accomplish well-defined tasks ("send a
> mail to foo@bar.com", "using the word processor, copy this fancy printed
> layout"). Then, you see how they *expect* your software to work, you
> see in which places it doesn't behave like that, and you fix it. This
> produces very good results. For Git in particular this could be things
> like, "Import this project from SVN, fix a bug, commit the patch", or
> "You are a maintainer, merge in these two branches from two
> contributors".
>
I like it. So much so that I'll see if I can get a non-programmer at work
to do these tasks. Now... to assemble that task-list. Suggestions welcome.
>
> It's hard to know where to begin :) Do I need "git-cherry-pick" or
> "git-cherry"? Why is the "apply a patch" command called "git-am"? Why
> is it different from "git-apply"? From "git-applypatch"? Etc.
>
I agree completely. It wouldn't be hard to make git-apply figure out if
it's being fed something that 'am' would normally want, and if it's being
fed it inside a git repo. If so, make it work just like 'am'.
git-applypatch was deprecated a long time ago and has already been removed.
Personally, I can't help but think that the numerous times I've heard "oh
gods, that's a lot of commands" should finally mean something. I've started
taking a look at which of them one can bundle together. If we can drop the
porcelainish commands down to ~30 or so, and hide the plumbing from git-<tab>
listings, the initial hurdle people have to jump would be significantly lower.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (thePATH)
From: Scott R Parish @ 2007-10-20 8:12 UTC (permalink / raw)
To: Johannes Schindelin, git
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
>
>
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Scott R Parish @ 2007-10-20 8:13 UTC (permalink / raw)
To: Johannes Schindelin, git, spearce, gitster
Wow, that sure cleaned up nicely! :)
Thanks
sRp
----- Original Message -----
Subject: [PATCH] Deduce exec_path also from calls to git with a relative path
Date: Sat, October 20, 2007 0:21
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> There is already logic in the git wrapper to deduce the exec_path from
> argv[0], when the git wrapper was called with an absolute path. Extend
> that logic to handle relative paths as well.
>
> For example, when you call "../../hello/world/git", it will not turn
> "../../hello/world" into an absolute path, and use that.
>
> Initial implementation by Scott R Parish.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Fri, 19 Oct 2007, Scott R Parish wrote:
>
> > Signed-off-by: Scott R Parish <srp@srparish.net>
>
> That is a little short for a commit message ;-)
>
> > git.c | 35 +++++++++++++++++++++++++++++++++--
> > 1 files changed, 33 insertions(+), 2 deletions(-)
>
> I had commented on this before. Probably I did a very bad job
> at explaining things, so hopefully this is better:
>
> git.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/git.c b/git.c
> index d7c6bca..1dad764 100644
> --- a/git.c
> +++ b/git.c
> @@ -414,13 +414,14 @@ int main(int argc, const char **argv)
> /*
> * Take the basename of argv[0] as the command
> * name, and the dirname as the default exec_path
> - * if it's an absolute path and we don't have
> - * anything better.
> + * if we don't have anything better.
> */
> if (slash) {
> *slash++ = 0;
> if (*cmd == '/')
> exec_path = cmd;
> + else
> + exec_path = xstrdup(make_absolute_path(cmd));
> cmd = slash;
> }
>
> --
> 1.5.3.4.1287.g8b31e
>
> -
> 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
>
>
^ permalink raw reply
* [PATCH] On error, do not list all commands, but point to --help option.
From: Jari Aalto @ 2007-10-20 8:24 UTC (permalink / raw)
To: git
- commented out call to list_common_cmds_help()
- Send error message to stderr, not stdout.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
help.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..dc9e59f 100644
--- a/help.c
+++ b/help.c
@@ -185,8 +185,8 @@ static void show_man_page(const char *git_cmd)
void help_unknown_cmd(const char *cmd)
{
- printf("git: '%s' is not a git-command\n\n", cmd);
- list_common_cmds_help();
+ fprintf(stderr, "git: '%s' is not a git-command. See --help\n\n", cmd);
+ /* list_common_cmds_help(); */
exit(1);
}
--
1.5.3.2.81.g17ed
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-20 8:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joakim Tjernlund, git
In-Reply-To: <Pine.LNX.4.64.0710182258000.25221@racer.site>
On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:
>
> On Thu, 18 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
>>
>>> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>>>
>>>> Seems like it is a bit too easy to make mistakes here. Why can I
>>>> delete
>>>> a branch with :linus but not create one with linus:linus?
>>>
>>> I wonder why you bother with the colon at all. Just
>>>
>>> git push <remote> linus
>>>
>>> and be done with it. The colon is only there to play interesting
>>> games,
>>> not something as simple as "push this branch" or "push this tag".
>>
>> But you need a full refspec starting with 'refs/heads/' if you
>> want to
>> create a new branch on the remote side.
>
> No. Not if the name is the same on the local side.
You're right. The documentation of git-send-pack says what you're
saying:
'''
When one or more <ref> are specified explicitly, it can be either a
single pattern, or a pair of such pattern separated by a colon
":" (this means that a ref name cannot have a colon in it). A single
pattern <name> is just a shorthand for <name>:<name>
'''
Here it says that <name> is a shorthand for <name>:<name>.
An later it states
'''
If <dst> does not match any remote ref, either
* it has to start with "refs/"; <dst> is used as the destination
literally in this case.
* <src> == <dst> and the ref that matched the <src> must not
exist in the set of remote refs; the ref matched <src> locally is
used as the name of the destination.
'''
If <src> == <dst> then <dst> will be created even if it didn't exist.
I think the current implementation though is a bit different.
It will created a new branch for a colon-less refspec, that is
git push origin work/topic
will create a new ref on the remote. But
git push origin work/topic:work/topic
will _not_.
Until you corrected me, I believed that new branches will never
be created on the remote side unless a full ref is used. That is
I expected that only
git push origin refs/heads/work/topic
would work.
I thought this would be another safety net -- kind of a reminder
not to push the wrong branch by accident.
I still like the idea, but apparently git didn't ever support what
I thought it would.
Maybe adding some command line flags making the different tasks
explicit could help:
git push --create origin work/new-topic
git push --delete origin work/old-topic
git push --non-standard origin refs/funny/ref
We already have similar flags
--all: all branches
--tags: all tags
--force: force non-fast-forward.
I haven't fully thought this through. Maybe I'll come up with a patch
later.
Steffen
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-20 8:38 UTC (permalink / raw)
To: Shawn O. Pearce, Lars Hjemli, Johannes Schindelin
Cc: Joakim Tjernlund, Git Mailing List
In-Reply-To: <5513C211-DE33-411C-8EE6-2259B41DC3EA@zib.de>
Shawn,
sp/push-refspec definitely needs more work (see below).
On Oct 20, 2007, at 10:29 AM, Steffen Prohaska wrote:
>
> On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:
>
>>
>> On Thu, 18 Oct 2007, Steffen Prohaska wrote:
>>>
>>> But you need a full refspec starting with 'refs/heads/' if you
>>> want to
>>> create a new branch on the remote side.
>>
>> No. Not if the name is the same on the local side.
>
> You're right. The documentation of git-send-pack says what you're
> saying:
>
> [...]
>
> Until you corrected me, I believed that new branches will never
> be created on the remote side unless a full ref is used. That is
> I expected that only
>
> git push origin refs/heads/work/topic
>
> would work.
>
> I thought this would be another safety net -- kind of a reminder
> not to push the wrong branch by accident.
>
> I still like the idea, but apparently git didn't ever support what
> I thought it would.
And I even fixed the behavior to match my expectation in a patch
which made it to spearce/pu:
d869233c62688742968663c4e8b5ff20a50a5011
push, send-pack: fix test if remote branch exists for colon-less
refspec
A push must fail if the remote ref does not yet exist and the
refspec
does not start with refs/. Remote refs must explicitly be
created with
their full name.
This commit adds some tests and fixes the existence check in
send-pack.
sp/push-refspec definitely needs some more work.
Steffen
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-20 10:19 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Federico Mena Quintero, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <4719B655.90204@op5.se>
On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:
>
> Personally, I can't help but think that the numerous times I've
> heard "oh
> gods, that's a lot of commands" should finally mean something. I've
> started
> taking a look at which of them one can bundle together. If we can
> drop the
> porcelainish commands down to ~30 or so, and hide the plumbing from
> git-<tab>
> listings, the initial hurdle people have to jump would be
> significantly lower.
Maybe we could group commands into more categories?
plumbing: should be hidden from the 'normal' user. Porcelain
should be sufficient for every standard task.
core porcelain: this is what everyone needs who works in a
pure git based workflow based on push/pull. You can't use
git without these commands. But these commands are already
sufficient to solve most of your tasks.
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.
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.
admin: Some commands are not used in a typical workflow. For
example git-filter-branch or git-fsck have a more admin
flavor.
There might be more categories. I am not sure because there
a quite a few commands that I _never_ used and have no clear
idea about what they do.
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.
Another section in the manual should describe a workflow based
on sending patches around. Obviously the mail porcelain is
needed for this.
... and so forth.
I don't know if we really want to hide the commands from PATH.
But maybe we should consider grouping them into subdirectories,
or provide another way to for the user to focus on the core
porcelain.
Steffen
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Paul Mackerras @ 2007-10-20 10:16 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Shawn O. Pearce
In-Reply-To: <200710191544.22228.barra_cuda@katamail.com>
Michele Ballabio writes:
> This patch indroduces a check before unsetting an array element.
introduces
> There's an error that seems to occur in gitk only on
> mutt's imported repo, but I don't know why. This is
> hopefully the right fix.
Well no. I'd rather understand why this is happening, in case the
error indicates that I'm not handling a corner case correctly. Can
you make a copy of the repo that triggers the bug available to me?
Paul.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Wincent Colaiuta @ 2007-10-20 11:02 UTC (permalink / raw)
To: Ari Entlich; +Cc: Michael Witten, Jeff King, git
In-Reply-To: <1192859753.13347.147.camel@g4mdd.entnet>
El 20/10/2007, a las 7:55, Ari Entlich escribió:
>> I'm thinking of occasions where you just want to do something
>> like:
>>
>> git mv --cached foo bar
>> git add --interactive bar
>
> I think it would be the other way around, since the only time this
> change would effect anything is when there are changes still
> waiting to
> be staged.
Well, my point was that sometimes you want to rename a dirty file
*right now* without having your modifications staged in the index
yet, and only later go ahead and stage the hunks (or the whole file)
when they're ready.
Basically, without this feature you have to manually unstage the
stuff that you don't want staged:
[hack on dirty foo]
git mv foo bar
[oops... you just staged unfinished changes]
git reset HEAD bar
[hack until bar is ready]
git add bar
So in order to unstage the stuff that wasn't ready you unstaged the
whole file and had to re-add it later, in which case what was the
point of using "git-mv" in the first place? You may as well have just
done:
[hack on dirty foo]
mv foo bar
[hack until bar is ready]
git rm foo
git add bar
The other alternative is to use git-stash:
[hack on dirty foo]
git stash
git mv foo bar
git stash apply
[hack until bar is ready]
git add bar
So, yes, you can do this with git-stash. It just means that "git-mv --
cached" would be a convenient short-cut.
> Are you talking about REALLY only changing the index?
No, sorry, I didn't make that clear. I meant that "git mv --cached
foo bar" would have the following effect (which if I understand it
correctly is basically what you proposed in your first email):
1. Copying "foo" directly to "bar" (even if dirty).
2. When adding "bar" to the the index add the blob corresponding to
"foo" as it is staged in the index (or at the HEAD if there are no
staged changes).
3. Removing the old file "foo".
The actual mechanics of this don't matter; those are just the
perceived effects. You could get exactly the same perceived effects
by doing it this way:
1. Creating a new file (or overwriting an existing one) named "bar",
whose contents would match those of the file "foo" not as it appears
in the working tree but as it is staged in the index.
2. If "foo" has unstaged changes, they should be applied to "bar" as
well (but not staged).
3. Removing the old file "foo".
> In addition, I don't think giving
> --interactive a filename is meaningful...
Whoops. I think I just inadvertently proposed a feature... my most
common use of "git-add --interactive" is when I want to stage only
specific hunks of a particular file, and so instead of typing "git
add bar" I want to type "git add -i bar" and have it jump straight to
the "patch" subcommand (5) for that file. Would anyone else find this
useful?
Cheers,
Wincent
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-20 11:06 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Ari Entlich, Michael Witten, git
In-Reply-To: <B6FFD723-83FF-459B-AD00-89DD2A3113DB@wincent.com>
On Sat, Oct 20, 2007 at 01:02:32PM +0200, Wincent Colaiuta wrote:
> Whoops. I think I just inadvertently proposed a feature... my most common
> use of "git-add --interactive" is when I want to stage only specific hunks
> of a particular file, and so instead of typing "git add bar" I want to type
> "git add -i bar" and have it jump straight to the "patch" subcommand (5) for
> that file. Would anyone else find this useful?
Yes, my only use of git-add --interactive is to stage particular patches
from individual files. So I would find that feature useful.
-Peff
^ permalink raw reply
* Re: gitk patch collection pull request
From: Jonathan del Strother @ 2007-10-20 11:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18200.36704.936554.220173@cargo.ozlabs.ibm.com>
On 19 Oct 2007, at 12:05, Paul Mackerras wrote:
> Shawn O. Pearce writes:
>
>> The following changes since commit
>> 719c2b9d926bf2be4879015e3620d27d32f007b6:
>> Paul Mackerras (1):
>> gitk: Fix bug causing undefined variable error when cherry-
>> picking
>>
>> are available in the git repository at:
>>
>> git://repo.or.cz:/git/spearce.git gitk
>
> OK, but ...
>
>> Jonathan del Strother (2):
>> gitk: Added support for OS X mouse wheel
>> Fixing gitk indentation
>
> This one is bogus. Firstly, it doesn't have "gitk:" at the start of
> the headline (and "Fixing" should be "Fix"). Secondly, the actual
> change itself is bogus. It changes an initial tab to 8 spaces on each
> of 4 lines. I like it the way it is - and if he wanted to change it,
> he should have changed it throughout the file, not just on 4 lines.
> So that change is rejected.
In my defense, most of that file is space indented, and the places
that are tab indented are generally totally broken unless you have an
8 char tab width. It seems to have the whole 'tabs for code
indentation, with space for alignment' rule back-to-front. I can't
follow the logic of that, so didn't feel comfortable changing the
whole file. I probably shouldn't have submitted the second patch - I
initially fixed the weird indentation in my first patch, just so my if-
block didn't look totally weird, but then was told that ought to be 2
separate patches.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Wincent Colaiuta @ 2007-10-20 11:15 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <8D972813-2D7F-4D6A-958F-B76E947E7BC3@MIT.EDU>
El 20/10/2007, a las 8:45, Michael Witten escribió:
> On 20 Oct 2007, at 2:36:28 AM, Shawn O. Pearce wrote:
>
>> Today I move the file, then unstage the hunks I'm not sure about,
>> then go back and restage them. Annoying. It really disrupts
>> my workflow.
>
> I know it's against policy, but the proposed change should be set
> as the default at some point, in my opinion.
I think the issue here is that git-mv as it is currently implemented
really conflates two things:
1. Renaming a file in the traditional "mv" sense
2. Staging the entire contents of the file in the index, ready or not
So it's kind of like the command were called git-mv-and-add or git-
rename-and-add. And given that the index as a staging area is such a
central content in Git, users often want to have more control over
what gets added to the index than that; ie. "I really just wanted to
rename the file, and leave the staging of modifications to the
content up to me".
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] gitk: add check for required tcl version >= 8.4
From: Paul Mackerras @ 2007-10-20 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <7vlkaplsu1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> From: Steffen Prohaska <prohaska@zib.de>
> Date: Fri, 28 Sep 2007 22:57:22 +0200
>
> gitk requires tcl version >= 8.4 to work flawlessly. So let's
> check the tcl version and quit if it's too low.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>
> * I do not have a ready access to older tcl/tk myself, so I
> cannot judge if this is sensible or not. Just forwarding in
> case you missed it.
Thanks for the patch. I have put in something similar using the
package require command, and using show_error to display the error in
a window.
Paul.
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Wincent Colaiuta @ 2007-10-20 11:20 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Steffen Prohaska, Evan Carroll, git
In-Reply-To: <8e04b5820710200040q76301c58j33e5d0895956b150@mail.gmail.com>
El 20/10/2007, a las 9:40, Ciprian Dorin Craciun escribió:
> 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 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...
But Git already has its own easy-to-edit, official wiki:
http://git.or.cz/gitwiki
Creating a separate wiki book seems like an unnecessary duplication
of effort.
(Obviously, you or anybody else is free to contribute documentation
wherever you want.)
Cheers,
Wincent
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-20 11:29 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Federico Mena Quintero, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de>
Steffen Prohaska wrote:
>
> On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:
>
>>
>> Personally, I can't help but think that the numerous times I've heard "oh
>> gods, that's a lot of commands" should finally mean something. I've
>> started
>> taking a look at which of them one can bundle together. If we can drop
>> the
>> porcelainish commands down to ~30 or so, and hide the plumbing from
>> git-<tab>
>> listings, the initial hurdle people have to jump would be
>> significantly lower.
>
> Maybe we could group commands into more categories?
>
> plumbing: should be hidden from the 'normal' user. Porcelain
> should be sufficient for every standard task.
>
Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
it.
> core porcelain: this is what everyone needs who works in a
> pure git based workflow based on push/pull. You can't use
> git without these commands. But these commands are already
> sufficient to solve most of your tasks.
>
Agreed.
> 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.
>
Disagreed, for obvious reasons. Many OSS projects are patch-centric
and developed much like git. OTOH, having to run "git format-patch"
rather than "git-format-patch" probably isn't so hampering that we
can't live with it.
> 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.
>
But very nifty for incremental imports. I track several CVS repos
that I continuously import. They're also self-explanatory, so
they don't add much to the clutter. Same reasons as above though;
there's no real reason not to invoke them as "git cvsimport" rather
than "git-cvsimport".
> admin: Some commands are not used in a typical workflow. For
> example git-filter-branch or git-fsck have a more admin
> flavor.
>
git-filter-branch could definitely live its life hidden somewhere.
git-fsck probably should stay with the plumbing, as it's used by
other porcelainish programs more often than run directly by the
user.
> There might be more categories. I am not sure because there
> a quite a few commands that I _never_ used and have no clear
> idea about what they do.
>
>
> 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.
>
Note that this is already possible, using a libexec-dir and
passing --exec-dir to the git wrapper. The only thing that isn't
done is deciding what's *definitely* plumbing. Once that's defined,
the makefile can install plumbing to a separate directory and
the /usr/bin/git-<tab> should shrink by roughly half.
> Another section in the manual should describe a workflow based
> on sending patches around. Obviously the mail porcelain is
> needed for this.
>
> ... and so forth.
>
> I don't know if we really want to hide the commands from PATH.
> But maybe we should consider grouping them into subdirectories,
> or provide another way to for the user to focus on the core
> porcelain.
>
Hiding the really core plumbing and getting rid of redundant
programs (git-am, git-apply, git-applypatch, ...) would do wonders,
methinks.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Paul Mackerras @ 2007-10-20 11:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070922050446.GA28467@spearce.org>
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?
Paul.
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-20 11:46 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Shawn O. Pearce, git
In-Reply-To: <531A500E-667F-413C-BD20-D23DC817EB72@steelskies.com>
Jonathan del Strother writes:
> In my defense, most of that file is space indented, and the places
Only the lines that are indented 1 level start with spaces. Any line
that is indented 2 or more levels should start with a tab.
> that are tab indented are generally totally broken unless you have an
> 8 char tab width.
So set your tabs to 8 spaces when looking at it. :)
> It seems to have the whole 'tabs for code
> indentation, with space for alignment' rule back-to-front.
I don't recall signing up to that rule. :) I use 4-column indentation
and 8-column tabs, and my editor (emacs) handles it all automatically
for me.
Paul.
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-20 11:52 UTC (permalink / raw)
To: 'Steffen Prohaska', 'Johannes Schindelin'; +Cc: 'git'
In-Reply-To: <5513C211-DE33-411C-8EE6-2259B41DC3EA@zib.de>
> -----Original Message-----
> From: Steffen Prohaska [mailto:prohaska@zib.de]
> Sent: den 20 oktober 2007 10:30
> To: Johannes Schindelin
> Cc: Joakim Tjernlund; git
> Subject: Re: git push bug?
>
>
> On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:
>
> >
> > On Thu, 18 Oct 2007, Steffen Prohaska wrote:
> >
> >> On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
> >>
> >>> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >>>
> >>>> Seems like it is a bit too easy to make mistakes here.
> Why can I
> >>>> delete
> >>>> a branch with :linus but not create one with linus:linus?
> >>>
> >>> I wonder why you bother with the colon at all. Just
> >>>
> >>> git push <remote> linus
> >>>
> >>> and be done with it. The colon is only there to play
> interesting
> >>> games,
> >>> not something as simple as "push this branch" or "push this tag".
> >>
> >> But you need a full refspec starting with 'refs/heads/' if you
> >> want to
> >> create a new branch on the remote side.
> >
> > No. Not if the name is the same on the local side.
>
> You're right. The documentation of git-send-pack says what you're
> saying:
>
> '''
> When one or more <ref> are specified explicitly, it can be either a
> single pattern, or a pair of such pattern separated by a colon
> ":" (this means that a ref name cannot have a colon in it). A single
> pattern <name> is just a shorthand for <name>:<name>
> '''
>
> Here it says that <name> is a shorthand for <name>:<name>.
> An later it states
>
> '''
> If <dst> does not match any remote ref, either
> * it has to start with "refs/"; <dst> is used as the destination
> literally in this case.
> * <src> == <dst> and the ref that matched the <src> must not
> exist in the set of remote refs; the ref matched <src> locally is
> used as the name of the destination.
> '''
>
> If <src> == <dst> then <dst> will be created even if it didn't exist.
>
> I think the current implementation though is a bit different.
> It will created a new branch for a colon-less refspec, that is
>
> git push origin work/topic
>
> will create a new ref on the remote. But
>
> git push origin work/topic:work/topic
>
> will _not_.
>
>
> Until you corrected me, I believed that new branches will never
> be created on the remote side unless a full ref is used. That is
> I expected that only
>
> git push origin refs/heads/work/topic
>
> would work.
>
> I thought this would be another safety net -- kind of a reminder
> not to push the wrong branch by accident.
>
> I still like the idea, but apparently git didn't ever support what
> I thought it would.
>
> Maybe adding some command line flags making the different tasks
> explicit could help:
>
> git push --create origin work/new-topic
> git push --delete origin work/old-topic
> git push --non-standard origin refs/funny/ref
This makes much more sense than the current method, thanks.
Jocke
^ permalink raw reply
* Re: git push bug?
From: Jan Hudec @ 2007-10-20 12:05 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: 'Johannes Schindelin', 'Steffen Prohaska',
'git'
In-Reply-To: <000001c81280$ebc5c5e0$5267a8c0@Jocke>
[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]
On Fri, Oct 19, 2007 at 20:50:29 +0200, Joakim Tjernlund wrote:
> On den 19 oktober 2007 19:25, Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de] wrote:
> > It strikes me as really odd that you would _want_ to create a branch
> > remotely, that has _never_ existed locally.
> It strikes me as really odd that a core developers like yourself
> hasn't tried to justify/explain why push works as it does.
Dscho it rarely kind to newbies.
> As I am trying to convince our dev. group here to move to git instead of subversion, I
> need to learn how git works. Now I have gotten to the push function and I need
> to know what can be done with push and how, pitfalls too. As I go along I find behavior
> that I find odd and report these to the list.
>
> git push <repo> v2.6.23:refs/heads/linus
> will make a tag look like a branch
That's becasue tags come in two flavors -- annotated and unannotated.
Annotated ones don't point to commits directly, but via 'tag' objects, that
contain description and usually signature.
Now git push will simply assign a remote branch whatever value you give it.
You gave it a tag, so it assigned a tag.
> git push <repo> linus:linus
> won't let me create the remote branch linus but
> git push <repo> linus
> will
Because in the former you are not saying whether refs/heads/linus,
refs/tags/linus or something else (the fact that heads and tags are treated
specially by git does not mean refs can't have other subdirectories -- it
can).
On the other hand in the later it resolves the ref locally and uses the same
name remotedly.
> git push <repo> :linus
> OOPS, now I just deleted remote branch linus, no warning
Your commands are quite obvious. No need for warning. (Besides, isn't there
a reflog?)
> git push <repo> linus:refs/head/linus
> creates a branch that is invisible(wont show in git branch -a)
It does not create a branch. It creates a ref with slightly funny name (it's
refs/heads, not refs/head).
^
> git push <repo> linus:refs/heads/newbranch
> creates remote branch newbranch, but you have to know the magic words
> refs/heads/ to do it.
Because you could have wanted a tag. Or a remote. Or something completely
different, maybe because some add-on uses (eg. stgit uses refs/bases and
refs/patches, IIRC).
> Se what I mean?
To me it all looks perfectly consistent. But maybe the documentation should
state more clearly, that push works in terms of arbitrary refs, NOT branches.
Feel free to post a documentation patch (people who just had hard time
finding something out are usually better at explaining it than old-timers who
consider it obvious).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: David Brown @ 2007-10-20 12:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott R Parish, git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710200818410.25221@racer.site>
On Sat, Oct 20, 2007 at 08:21:34AM +0100, Johannes Schindelin wrote:
>For example, when you call "../../hello/world/git", it will not turn
>"../../hello/world" into an absolute path, and use that.
Did you mean "it will turn..."?
David
^ permalink raw reply
* Re: gitk patch collection pull request
From: Jonathan del Strother @ 2007-10-20 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18201.60047.898077.579869@cargo.ozlabs.ibm.com>
On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
> Jonathan del Strother writes:
>
>> In my defense, most of that file is space indented, and the places
>
> Only the lines that are indented 1 level start with spaces. Any line
> that is indented 2 or more levels should start with a tab.
>> It seems to have the whole 'tabs for code
>> indentation, with space for alignment' rule back-to-front.
>
> I don't recall signing up to that rule. :) I use 4-column indentation
> and 8-column tabs, and my editor (emacs) handles it all automatically
> for me.
Ugh... I don't usually get involved in tab/space wars, but I'm
curious... why on earth would you choose this style?
With space indentation you can make sure that everyone sees the
indentation as it was intended. With tab indentation, you save space,
add semantic meaning, and let people control how wide they want their
indents to appear. This approach seems to take the worst parts of
each and combine them. What's the benefit?
I appreciate I'm not going to convert you - this is an honest question.
^ permalink raw reply
* [PATCH 1/2] git-gui: Add more terms to glossary.
From: Christian Stimming @ 2007-10-20 13:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071010060328.GO2137@spearce.org>
---
Based on git-gui.git's master.
po/glossary/git-gui-glossary.pot | 8 ++++++--
po/glossary/git-gui-glossary.txt | 3 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/po/glossary/git-gui-glossary.pot b/po/glossary/git-gui-glossary.pot
index a2e5c73..48af803 100644
--- a/po/glossary/git-gui-glossary.pot
+++ b/po/glossary/git-gui-glossary.pot
@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2007-10-05 22:30+0200\n"
+"POT-Creation-Date: 2007-10-19 21:43+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
@@ -86,7 +86,7 @@ msgstr ""
msgid "message"
msgstr ""
-#. ""
+#. "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
msgid "prune"
msgstr ""
@@ -102,6 +102,10 @@ msgstr ""
msgid "redo"
msgstr ""
+#. "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
+msgid "remote"
+msgstr ""
+
#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
msgid "repository"
msgstr ""
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
index b53740d..500d0a0 100644
--- a/po/glossary/git-gui-glossary.txt
+++ b/po/glossary/git-gui-glossary.txt
@@ -16,10 +16,11 @@
"merge [noun]" "A successful merge results in the creation of a new commit representing the result of the merge."
"merge [verb]" "To bring the contents of another branch into the current branch."
"message" ""
-"prune" ""
+"prune" "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
"pull" "Pulling a branch means to fetch it and merge it."
"push" "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
"redo" ""
+"remote" "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
"repository" "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
"reset" ""
"revert" ""
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox