* Converting a directory to submodule
From: Paul Sadauskas @ 2007-11-30 17:53 UTC (permalink / raw)
To: git
Dear list,
I'm having some trouble when I change an existing directory in a
project into a submodule. After pushing this change to the origin, I
can no longer pull into any other projects. I can, however, clone the
origin without problems.
These are the steps I take to change the dir into a submod:
rm -rf /submod
git commit -a
git submodule add git://abc/submod submod
git commit
git push
But then attempting to pull this anywhere else results in a
half-completed pull, and dies with the error:
fatal: cannot read object bb138891993fdeb3dbfcb41fe8c2a4693676f8fe
'submod~564e58282ce575db34b6f249a42b1ea59f56efd3'
Merge with strategy recursive failed.
Like I said, though, a fresh clone works fine. Am I doing something
wrong in my push, or is this a bug?
Thanks,
Paul Sadauskas
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jan Hudec @ 2007-11-30 17:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711291200000.27959@racer.site>
On Thu, Nov 29, 2007 at 12:01:47 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Jan Hudec wrote:
>
> > On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:
> >
> > > Furthermore, my complaint was not about a platform where neither C#
> > > nor Python work. That is irrelevant. If you have one platform where
> > > only one works, and another platform where only the other works, you
> > > cannot have a single program for both platforms. Right?
> >
> > Right.
> >
> > I probably shouldn't be surprised that mono does not work on older unices,
> > but I am a bit surprised python does not.
>
> *Sigh* I managed again to make myself misunderstood.
>
> Even if newer Python does not easily compile on that IRIX, I have an old
> Python there (2.2). But I don't have any Python on MSys. (Yes, there is
> a _MinGW_ port, but no _MSys_ one.) So for me, Python is out.
While it would be a problem, but is it really fatal? AFAIK MSys uses unixy
paths inside the program, but accepts arguments and calls other processes
using the windows convention, so mingw python should have no problem calling
msys programs and vice versa. It might be more problematic to compile
a shared module for it, but .dlls are quite well isolated, so even compiling
a plugin linked with msys for mingw python might not be impossible.
Nevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting
it in python nor any other language would probably help it in any way.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
From: Bill Priest @ 2007-11-30 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 28 Nov 2007 12:08:40 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> You can still do that by hand, by doing something
like:
>
> $ git merge --squash A
> $ resolve only partly
> $ git commit -m 'Prepare to merge A'
> $ git reset --hard
> $ git merge A
> $ resolve the rest
> $ git commit -m 'Fully merged A'
>
> For such a multi-step merge to make sense, the
change between B---M
> should make sense by itself for people who have to
read such a history
> later. Such a half-a-squash-merge may probably not
make sense by itself
> in most cases, so I suspect the above workflow would
not be useful in
> general.
>
Junio,
I resolved all the merges and then committed
different files as groups to make it easy to
cherry-pick after this merge. Does this "mess up" the
merge info? What does the "git reset --hard" do after
the commit (I'm assuming it throws away the
non-resolved changes not committed)? But from my
experience git wouldn't let me do the commit above it
w/o first fixing the conflicts.
Am I mis-interpreting your example or are you saying
that you think git would let me do the commit w/o
resolving all conflicts?
Bill
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 16:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Santi B?jar, Steffen Prohaska, Junio C Hamano,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.9999.0711300745330.8458@woody.linux-foundation.org>
On Fri, Nov 30, 2007 at 07:50:47AM -0800, Linus Torvalds wrote:
> Well, different people will want different viewers *anyway* (ie some will
> prefer qgit etc), so how about making "git view" be something that
> literally acts as a built-in alias that just defaults to running gitk (if
> for no other reason than the fact that gitk is the one that ships with
> git, and simply has most users).
I think that is a good idea, and here's a patch.
-- >8 --
Support builtin aliases
Builtin aliases are "default" alias values that can be
overridden by user-configured aliases.
For example, the first such alias is "view", an alias for
gitk. A user with no further configuration can run
"git view" to use gitk. However, they can also set the
config option "alias.view" to "!tig" to run tig.
---
git.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index f220284..95296aa 100644
--- a/git.c
+++ b/git.c
@@ -151,6 +151,13 @@ static int split_cmdline(char *cmdline, const char ***argv)
return count;
}
+static char *builtin_alias(const char *cmd)
+{
+ if (!strcmp(cmd, "view"))
+ return xstrdup("!gitk");
+ return NULL;
+}
+
static int handle_alias(int *argcp, const char ***argv)
{
int nongit = 0, envchanged = 0, ret = 0, saved_errno = errno;
@@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)
alias_command = (*argv)[0];
git_config(git_alias_config);
+ if (!alias_string)
+ alias_string = builtin_alias(alias_command);
if (alias_string) {
if (alias_string[0] == '!') {
if (*argcp > 1) {
--
1.5.3.6.2064.g2e22f-dirty
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Linus Torvalds @ 2007-11-30 15:50 UTC (permalink / raw)
To: Jeff King
Cc: Santi B?jar, Steffen Prohaska, Junio C Hamano,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130152942.GA22489@coredump.intra.peff.net>
On Fri, 30 Nov 2007, Jeff King wrote:
>
> On Fri, Nov 30, 2007 at 04:28:21PM +0100, Santi Béjar wrote:
> > > But I am not opposed to having some "git foo" form for gitk.
> >
> > In mercurial "hg view" is actually an old version of gitk modified for hg.
> >
> > And as "git view" it could be added to the "git help" list.
>
> Unfortunately, there is already a "gitview" program similar to gitk,
> although it never made it out of contrib/.
Well, different people will want different viewers *anyway* (ie some will
prefer qgit etc), so how about making "git view" be something that
literally acts as a built-in alias that just defaults to running gitk (if
for no other reason than the fact that gitk is the one that ships with
git, and simply has most users).
There's a few other things that I think we could consider to be good
built-in aliases: things like "git cat" being an alias for "git -p
cat-file -p" etc.
The only difference between a "built-in alias" and a "built-in command"
would be:
- the alias has never even had the "git-xyz" format, and never will
- the alias can be overridden by user aliases unlike "real" git commands
Hmm?
That way we can hide away gitk too (although I do suspect that we might as
well just leave gitk in the path - it's different in naming from all the
git-xyz commands anyway)
Linus
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 15:29 UTC (permalink / raw)
To: Santi Béjar
Cc: Steffen Prohaska, Linus Torvalds, Junio C Hamano,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <8aa486160711300728x70f591f1hf8884a78f2b15806@mail.gmail.com>
On Fri, Nov 30, 2007 at 04:28:21PM +0100, Santi Béjar wrote:
> > But I am not opposed to having some "git foo" form for gitk.
>
> In mercurial "hg view" is actually an old version of gitk modified for hg.
>
> And as "git view" it could be added to the "git help" list.
Unfortunately, there is already a "gitview" program similar to gitk,
although it never made it out of contrib/.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Santi Béjar @ 2007-11-30 15:28 UTC (permalink / raw)
To: Jeff King
Cc: Steffen Prohaska, Linus Torvalds, Junio C Hamano,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130151223.GB22095@coredump.intra.peff.net>
On Nov 30, 2007 4:12 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:
>
> > What will happen to gitk?
> >
> > Shouldn't it be included in the nice collection? gitk is
> > an essential command. Then, following your reasoning,
> > "git <tab><tab>" should recommend it, no?
> >
> > Note, "git gui" already works. gitk would really be the last
> > git "command" that can't be accessed through "git <command>"
>
> Except for qgit, tig, etc. The only difference being that gitk actually
> ships with git.
>
> But I am not opposed to having some "git foo" form for gitk.
In mercurial "hg view" is actually an old version of gitk modified for hg.
And as "git view" it could be added to the "git help" list.
Santi
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 15:12 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Linus Torvalds, Junio C Hamano, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <5E2A9E2B-8B9A-46B0-99D0-DB3798F10119@zib.de>
On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:
> What will happen to gitk?
>
> Shouldn't it be included in the nice collection? gitk is
> an essential command. Then, following your reasoning,
> "git <tab><tab>" should recommend it, no?
>
> Note, "git gui" already works. gitk would really be the last
> git "command" that can't be accessed through "git <command>"
Except for qgit, tig, etc. The only difference being that gitk actually
ships with git.
But I am not opposed to having some "git foo" form for gitk.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-11-30 15:09 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Nicolas Pitre, Junio C Hamano, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <474FB938.3040209@op5.se>
On Fri, Nov 30, 2007 at 08:18:16AM +0100, Andreas Ericsson wrote:
>> The only reason I have heard to remove them entirely is that Windows
>> doesn't properly support hardlinks, which I addressed in my other mails
>> (and to which I have seen no rebuttal).
>>
> It would provide a ui inconsistency between platforms. Several people
> pointed that out. It's decidedly a Bad Thing.
Which, as I said, I have already addressed (and which Linus has also
expanded upon in this thread). Since those hardlinks would be hidden
from users who did not go to some trouble to find them, there will not
be inconsistency problems. Scripts will have to either go to some effort
to change their PATH, or simply use the correct form, and I expect them
to do the latter.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-11-30 13:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Eyvind Bernhardsen, Junio C Hamano, Nicolas Pitre, Jan Hudec, git
In-Reply-To: <fcaeb9bf0711300419i9cf70eo9f96e3a5e3f44585@mail.gmail.com>
Hi,
On Fri, 30 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 30, 2007 6:28 PM, Eyvind Bernhardsen
> <eyvind-git-list@orakel.ntnu.no> wrote:
> > On 29. nov. 2007, at 23.36, Junio C Hamano wrote:
> >
> > [...]
> >
> > > If people are really serious about reducing the number of commands in
> > > the path, I would expect fixes and bugreports saying "I am setting
> > > gitexecdir different from bindir in _my_ installation when I build
> > > git,
> > > and here are the things that does not work if I do so". Within the
> > > span
> > > of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I
> > > do not think there was a single such report or patch, other than the
> > > message from Nguyen that started this thread.
> >
> > I'm setting gitexecdir different from bindir in my installation, and
> > here are the things that don't work:
> >
> > - When pushing to my system over ssh, git-receive-pack and git-upload-
> > pack are expected to be in $PATH. I resolved the problem by putting
> > symlinks in /usr/local/bin.
> >
> > I haven't seen any other problems, but then again, I only use git
> > plumbing commands and my own scripts.
>
> You remind me my experience of making every external C-based command
> builtin. There is another case: git-merge. It calls something like
> git-merge-$strategy.
Good catch!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Johannes Sixt @ 2007-11-30 13:24 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <BDA3CE08-FFA4-4D84-A2FC-5810AAA6EEAB@MIT.EDU>
Michael Witten schrieb:
> On 30 Nov 2007, at 7:03:15 AM, Johannes Schindelin wrote:
>> On Thu, 29 Nov 2007, Michael Witten wrote:
>>> How about turning git-cvsserver into a true middleman, so that it
>>> constructs a 'temporary git working tree' and then does a real git-push
>>> into the final git repository.
>>
>> That would yield a horrible performance.
>>
>> Would be opposed, if a regular cvsserver user,
>
> How come?
>
> git-cvsserver it seems already does just that!
> The difference is that it puts objects in place
> by hand, requiring the code to mirror hook calls
> anyway.
>
> I'm simply proposing that the code be reworked,
> so that cvs commits actually become git pushes,
> so that all future changes to the pushing mechanism
> are automatically handled.
But in order push something, you must first have the commit in a repository.
How would git-cvsserver do that? For example, by putting objects in place by
hand. You gain nothing, except that it would push instead of call the hooks
directly.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Johannes Schindelin @ 2007-11-30 13:19 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Junio C Hamano
In-Reply-To: <BDA3CE08-FFA4-4D84-A2FC-5810AAA6EEAB@MIT.EDU>
Hi,
On Fri, 30 Nov 2007, Michael Witten wrote:
> On 30 Nov 2007, at 7:03:15 AM, Johannes Schindelin wrote:
>
> > On Thu, 29 Nov 2007, Michael Witten wrote:
> >
> > > In any case, I haven't taken a thorough look at how git-cvsserver
> > > works, but it seems to duplicate a lot of git-receive-pack.
> > >
> > > How about turning git-cvsserver into a true middleman, so that it
> > > constructs a 'temporary git working tree' and then does a real
> > > git-push into the final git repository.
> >
> > That would yield a horrible performance.
> >
> > Would be opposed, if a regular cvsserver user,
>
> How come?
I remember driving git-cvsserver on a bare repository, with "ln -s
/usr/bin/git-cvsserver ~cvsuser/bin/", and it was superfast.
One user even asked if I upgraded my cvs, because it was so much faster
than before. I said yes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Michael Witten @ 2007-11-30 12:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0711301202230.27959@racer.site>
On 30 Nov 2007, at 7:03:15 AM, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Michael Witten wrote:
>
>> In any case, I haven't taken a thorough look at how git-cvsserver
>> works,
>> but it seems to duplicate a lot of git-receive-pack.
>>
>> How about turning git-cvsserver into a true middleman, so that it
>> constructs a 'temporary git working tree' and then does a real git-
>> push
>> into the final git repository.
>
> That would yield a horrible performance.
>
> Would be opposed, if a regular cvsserver user,
How come?
git-cvsserver it seems already does just that!
The difference is that it puts objects in place
by hand, requiring the code to mirror hook calls
anyway.
I'm simply proposing that the code be reworked,
so that cvs commits actually become git pushes,
so that all future changes to the pushing mechanism
are automatically handled.
It just makes sense as far as design; git-cvsserver
should be an adaptor between the two kinds of repositories,
not an infiltrator.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nguyen Thai Ngoc Duy @ 2007-11-30 12:19 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Junio C Hamano, Nicolas Pitre, Jan Hudec, Johannes Schindelin,
git
In-Reply-To: <DB613F3E-85CC-4AF0-928C-4F4E4C8E9FB8@orakel.ntnu.no>
On Nov 30, 2007 6:28 PM, Eyvind Bernhardsen
<eyvind-git-list@orakel.ntnu.no> wrote:
> On 29. nov. 2007, at 23.36, Junio C Hamano wrote:
>
> [...]
>
> > If people are really serious about reducing the number of commands in
> > the path, I would expect fixes and bugreports saying "I am setting
> > gitexecdir different from bindir in _my_ installation when I build
> > git,
> > and here are the things that does not work if I do so". Within the
> > span
> > of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I
> > do not think there was a single such report or patch, other than the
> > message from Nguyen that started this thread.
>
> I'm setting gitexecdir different from bindir in my installation, and
> here are the things that don't work:
>
> - When pushing to my system over ssh, git-receive-pack and git-upload-
> pack are expected to be in $PATH. I resolved the problem by putting
> symlinks in /usr/local/bin.
>
> I haven't seen any other problems, but then again, I only use git
> plumbing commands and my own scripts.
You remind me my experience of making every external C-based command
builtin. There is another case: git-merge. It calls something like
git-merge-$strategy.
--
Duy
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Eyvind Bernhardsen @ 2007-11-30 11:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Nguyen Thai Ngoc Duy, Jan Hudec,
Johannes Schindelin, git
In-Reply-To: <7vd4tsvfvk.fsf@gitster.siamese.dyndns.org>
On 29. nov. 2007, at 23.36, Junio C Hamano wrote:
[...]
> If people are really serious about reducing the number of commands in
> the path, I would expect fixes and bugreports saying "I am setting
> gitexecdir different from bindir in _my_ installation when I build
> git,
> and here are the things that does not work if I do so". Within the
> span
> of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I
> do not think there was a single such report or patch, other than the
> message from Nguyen that started this thread.
I'm setting gitexecdir different from bindir in my installation, and
here are the things that don't work:
- When pushing to my system over ssh, git-receive-pack and git-upload-
pack are expected to be in $PATH. I resolved the problem by putting
symlinks in /usr/local/bin.
I haven't seen any other problems, but then again, I only use git
plumbing commands and my own scripts.
Eyvind
^ permalink raw reply
* [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Johannes Schindelin @ 2007-11-30 12:08 UTC (permalink / raw)
To: Eyvind Bernhardsen
Cc: Junio C Hamano, Nicolas Pitre, Nguyen Thai Ngoc Duy, Jan Hudec,
git
In-Reply-To: <DB613F3E-85CC-4AF0-928C-4F4E4C8E9FB8@orakel.ntnu.no>
Since we plan to move the dash-form (git-<whatever>) into an execdir, it
make sense to prepare our git protocol users for it.
Noticed by Eyvind Bernhardsen.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 30 Nov 2007, Eyvind Bernhardsen wrote:
> - When pushing to my system over ssh, git-receive-pack and
> git-upload-pack are expected to be in $PATH. I resolved the
> problem by putting symlinks in /usr/local/bin.
How about this? (I only compile-tested it...)
transport.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 50db980..7bd0846 100644
--- a/transport.c
+++ b/transport.c
@@ -736,10 +736,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->disconnect = disconnect_git;
data->thin = 1;
- data->uploadpack = "git-upload-pack";
+ data->uploadpack = "git upload-pack";
if (remote && remote->uploadpack)
data->uploadpack = remote->uploadpack;
- data->receivepack = "git-receive-pack";
+ data->receivepack = "git receive-pack";
if (remote && remote->receivepack)
data->receivepack = remote->receivepack;
}
--
1.5.3.6.2088.g8c260
^ permalink raw reply related
* Re: [PATCH (homepage)] Make git homepage (main page) use valid HTML
From: Jonas Fonseca @ 2007-11-30 12:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <200711301255.57012.jnareb@gmail.com>
On Nov 30, 2007 12:55 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Jonas Fonseca wrote:
> > BTW, the patch contained multiple wrapping problems. Don't know if
> > it is from your side or my broken use of GMail.
>
> I'm sorry, this was my mistake (forgot to turn off word wrapping when
> sending this patch). But as you have applied it, I don't need to
> resend, do I?
No.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Johannes Schindelin @ 2007-11-30 12:03 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Junio C Hamano
In-Reply-To: <7F81126E-5A76-40CA-94BF-82B46C57AFF6@mit.edu>
Hi,
On Thu, 29 Nov 2007, Michael Witten wrote:
> In any case, I haven't taken a thorough look at how git-cvsserver works,
> but it seems to duplicate a lot of git-receive-pack.
>
> How about turning git-cvsserver into a true middleman, so that it
> constructs a 'temporary git working tree' and then does a real git-push
> into the final git repository.
That would yield a horrible performance.
Would be opposed, if a regular cvsserver user,
Dscho
^ permalink raw reply
* Re: [PATCH (homepage)] Make git homepage (main page) use valid HTML
From: Jakub Narebski @ 2007-11-30 11:55 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <2c6b72b30711300342g1f8fffdbt8d300e6a35a7c92f@mail.gmail.com>
Jonas Fonseca wrote:
>
> I've applied this and your previous patch that added links to Windows
> binaries. Should be mirrored one pasky pushes his update button.
> BTW, the patch contained multiple wrapping problems. Don't know if
> it is from your side or my broken use of GMail.
I'm sorry, this was my mistake (forgot to turn off word wrapping when
sending this patch). But as you have applied it, I don't need to
resend, do I?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Johannes Schindelin @ 2007-11-30 11:50 UTC (permalink / raw)
To: Kevin Leung; +Cc: Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <e66701d40711300016v15700deft3d262d75a9055aca@mail.gmail.com>
Hi,
On Fri, 30 Nov 2007, Kevin Leung wrote:
> The current git-stash behaviour is very error prone to typos. For
> example, if you typed "git-stash llist", git-stash would thought that
> you wanted to save to a stash named "llist", but in fact, you meant
> "git-stash list".
I am fine with your patch. I would be equally fine with "git stash" still
choosing a default message and stashing.
And yes, I agree that the "git stash <whatever>" might be a little too
error-prone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (homepage)] Make git homepage (main page) use valid HTML
From: Jonas Fonseca @ 2007-11-30 11:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <200711301159.11290.jnareb@gmail.com>
On Nov 30, 2007 11:59 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> I hope that it would make through anti-SPAM filters...
I've applied this and your previous patch that added links to Windows
binaries. Should be mirrored one pasky pushes his update button.
> @@ -233,7 +235,6 @@ You can also use one of many <a
> href="http://www.kernel.org/mirrors/">kernel.org
> <td>Unstable</td>
> <td><a
> href="http://packages.debian.org/unstable/devel/git-core">http://packages.debian.org/unstable/devel/git-core</a></td>
> </tr>
> -</td>
>
> </table>
>
BTW, the patch contained multiple wrapping problems. Don't know if it is
from your side or my broken use of GMail.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] Replace the word 'update-cache' by 'update-index' everywhere
From: Johannes Schindelin @ 2007-11-30 11:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: christoph.duelli, git, gitster
In-Reply-To: <474FC2C5.8060400@op5.se>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/user-manual.txt | 2 +-
Makefile | 2 +-
configure.ac | 2 +-
t/t4000-diff-format.sh | 2 +-
t/t4001-diff-rename.sh | 2 +-
t/t4100/t-apply-1.patch | 2 +-
t/t4100/t-apply-2.patch | 2 +-
t/t4100/t-apply-5.patch | 2 +-
t/t4100/t-apply-6.patch | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0aaed10..93a47b4 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3707,7 +3707,7 @@ should use the `--remove` and `--add` flags respectively.
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-cache will be
+removed. The only thing `--remove` means is that update-index will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
diff --git a/Makefile b/Makefile
index 4454116..f000a5e 100644
--- a/Makefile
+++ b/Makefile
@@ -111,7 +111,7 @@ all::
# times (my ext3 doesn't).
#
# Define USE_STDEV below if you want git to care about the underlying device
-# change being considered an inode change from the update-cache perspective.
+# change being considered an inode change from the update-index perspective.
#
# Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
#
diff --git a/configure.ac b/configure.ac
index 7bcf1a4..5f8a15b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -415,7 +415,7 @@ GIT_PARSE_WITH(iconv))
# times (my ext3 doesn't).
#
# Define USE_STDEV below if you want git to care about the underlying device
-# change being considered an inode change from the update-cache perspective.
+# change being considered an inode change from the update-index perspective.
## Output files
diff --git a/t/t4000-diff-format.sh b/t/t4000-diff-format.sh
index 7d92ae3..c44b27a 100755
--- a/t/t4000-diff-format.sh
+++ b/t/t4000-diff-format.sh
@@ -16,7 +16,7 @@ cat path0 >path1
chmod +x path1
test_expect_success \
- 'update-cache --add two files with and without +x.' \
+ 'update-index --add two files with and without +x.' \
'git update-index --add path0 path1'
mv path0 path0-
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 877c1ea..a326924 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -27,7 +27,7 @@ Line 15
'
test_expect_success \
- 'update-cache --add a file.' \
+ 'update-index --add a file.' \
'git update-index --add path0'
test_expect_success \
diff --git a/t/t4100/t-apply-1.patch b/t/t4100/t-apply-1.patch
index de58751..f98baa8 100644
--- a/t/t4100/t-apply-1.patch
+++ b/t/t4100/t-apply-1.patch
@@ -90,7 +90,7 @@ diff --git a/Documentation/git.txt b/Documentation/git.txt
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
-@@ -30,7 +30,7 @@ PROG= git-update-cache git-diff-files
+@@ -30,7 +30,7 @@ PROG= git-update-index git-diff-files
git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
git-check-files git-ls-tree git-merge-base git-merge-cache \
git-unpack-file git-export git-diff-cache git-convert-cache \
diff --git a/t/t4100/t-apply-2.patch b/t/t4100/t-apply-2.patch
index cfdc808..f5c7d60 100644
--- a/t/t4100/t-apply-2.patch
+++ b/t/t4100/t-apply-2.patch
@@ -9,7 +9,7 @@ diff --git a/Makefile b/Makefile
- git-deltafy-script
+ git-deltafy-script git-fetch-script
- PROG= git-update-cache git-diff-files git-init-db git-write-tree \
+ PROG= git-update-index git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-pull-script b/git-fetch-script
similarity index 87%
diff --git a/t/t4100/t-apply-5.patch b/t/t4100/t-apply-5.patch
index de11623..ad45c51 100644
--- a/t/t4100/t-apply-5.patch
+++ b/t/t4100/t-apply-5.patch
@@ -200,7 +200,7 @@ diff a/Documentation/git.txt b/Documentation/git.txt
diff a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
-@@ -30,7 +30,7 @@ PROG= git-update-cache git-diff-files
+@@ -30,7 +30,7 @@ PROG= git-update-index git-diff-files
git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
git-check-files git-ls-tree git-merge-base git-merge-cache \
git-unpack-file git-export git-diff-cache git-convert-cache \
diff --git a/t/t4100/t-apply-6.patch b/t/t4100/t-apply-6.patch
index d975363..a72729a 100644
--- a/t/t4100/t-apply-6.patch
+++ b/t/t4100/t-apply-6.patch
@@ -8,7 +8,7 @@ diff a/Makefile b/Makefile
- git-deltafy-script
+ git-deltafy-script git-fetch-script
- PROG= git-update-cache git-diff-files git-init-db git-write-tree \
+ PROG= git-update-index git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff a/git-fetch-script b/git-fetch-script
--- /dev/null
--
1.5.3.6.2088.g8c260
^ permalink raw reply related
* [RFC/PATCH (homepage)] Add links to binaries for MS Windows (Cygwin, msysGit)
From: Jakub Narebski @ 2007-11-30 11:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
What links should be provided for Cygwin? I could only found net
installer... (setup.exe)...
index.html | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/index.html b/index.html
index 29fa0b1..142bd46 100644
--- a/index.html
+++ b/index.html
@@ -236,6 +236,16 @@ You can also use one of many <a href="http://www.kernel.org/mirrors/">kernel.org
<td><a href="http://packages.debian.org/unstable/devel/git-core">http://packages.debian.org/unstable/devel/git-core</a></td>
</tr>
+<tr>
+<td rowspan="2">Win</td>
+<td><a href="http://www.cygwin.com/">Cygwin</a></td>
+<td><a href="http://www.cygwin.com/setup.exe">http://www.cygwin.com/setup.exe</a></td>
+</tr>
+<tr class="odd">
+<td><a href="http://code.google.com/p/msysgit/">msysGit</a></td>
+<td><a href="http://code.google.com/p/msysgit/downloads/list">http://code.google.com/p/msysgit/downloads/list</a></td>
+</tr>
+
</table>
<h3>Development snapshots</h3>
--
1.5.3.6
^ permalink raw reply related
* [PATCH (homepage)] Make git homepage (main page) use valid HTML
From: Jakub Narebski @ 2007-11-30 10:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
Checked by W3C Markup Validation Service:
http://validator.w3.org
Most of those changes makes git homepage use valid XML / SGML;
the errors were incorrect ordering of closing tags, wrong closing
tags, spurious closing tags.
HTML declares that <p> element cannot contain other block elements
(at least not interspersed with text); correcting this also fixed
layout (in Mozilla), where part of paragraph after <pre> element
was not indented.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Resent.
I hope that it would make through anti-SPAM filters...
index.html | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/index.html b/index.html
index 01726f6..29fa0b1 100644
--- a/index.html
+++ b/index.html
@@ -88,7 +88,8 @@ Junio C Hamano.</p>
<h2 id="about">About Git</h2>
-<div style="float: right"><table class="releases">
+<div style="float: right">
+<table class="releases">
<tr><th><a href="course/index.html">Git Crash Courses</a></th></tr>
<tr><td align="center">
<a
href="http://www.kernel.org/pub/software/scm/git/docs/tutorial.html">Git
for everyone</a>
@@ -98,8 +99,9 @@ Junio C Hamano.</p>
<br /><a href="course/stgit.html">Maintaining external patches</a>
<br /><a href="course/svn.html">Git for SVN users</a>
<br /><em>More to come soon...</em>
- </tr></td>
-</table></div>
+ </td></tr>
+</table>
+</div>
<p>Git is distributed version control system focused on
speed, effectivity and real-world usability on large projects.
@@ -173,7 +175,7 @@ and are either porting an existing toolset to use
the Git tools,
or reimplementing the concepts internally,
to benefit from the performance improvements.
This includes e.g.
-<a href="http://wiki.darcs.net/DarcsWiki/DarcsGit">Darcs-git</a>.</li>
+<a href="http://wiki.darcs.net/DarcsWiki/DarcsGit">Darcs-git</a>.</p>
<hr />
@@ -223,7 +225,7 @@ You can also use one of many <a
href="http://www.kernel.org/mirrors/">kernel.org
<tr class="odd">
<td rowspan="3">Debs</td>
<td>Stable</td>
-<td><a
href="http://www.backports.org/debian/pool/main/g/git-core/">http://www.backports.org/debian/pool/main/g/git-core/</a></dd></td>
+<td><a
href="http://www.backports.org/debian/pool/main/g/git-core/">http://www.backports.org/debian/pool/main/g/git-core/</a></td>
</tr>
<tr>
<td>Testing</td>
@@ -233,7 +235,6 @@ You can also use one of many <a
href="http://www.kernel.org/mirrors/">kernel.org
<td>Unstable</td>
<td><a
href="http://packages.debian.org/unstable/devel/git-core">http://packages.debian.org/unstable/devel/git-core</a></td>
</tr>
-</td>
</table>
@@ -247,16 +248,14 @@ You can also use one of many <a
href="http://www.kernel.org/mirrors/">kernel.org
<h3>Git by git</h3>
<p>If you already have Git installed, you can get the latest
-development version via Git itself:
+development version via Git itself:</p>
<pre>git clone git://git.kernel.org/pub/scm/git/git.git</pre>
-</p>
<p>If you have problems connecting (Git uses port 9418),
-you can try to access the repository over the HTTP protocol:
+you can try to access the repository over the HTTP protocol:</p>
<pre>git clone http://www.kernel.org/pub/scm/git/git.git</pre>
-(this method is considerably slower but works even behind
-firewalls and such).
-</p>
+<p>(this method is considerably slower but works even behind
+firewalls and such).</p>
<p>You can also always browse the current contents
of the git repository on web using the kernel.org
--
1.5.3.6
^ permalink raw reply related
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Wincent Colaiuta @ 2007-11-30 9:19 UTC (permalink / raw)
To: Kevin Leung; +Cc: Mike Hommey, Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <e66701d40711300109nc43f3efyb33e591af15a060b@mail.gmail.com>
El 30/11/2007, a las 10:09, Kevin Leung escribió:
> On Nov 30, 2007 4:41 PM, Mike Hommey <mh@glandium.org> wrote:
>> Still, 'git stash' alone should *do* the stash.
>
> How about `git stash' still does the stash, and `git stash llist'
> exits with usage message? And if you want to save the stash with name,
> you can only do it with `git stash save name_of_stash'.
That's probably the way it should have been all along.
>
Cheers,
Wincent
^ 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