* Re: [PATCH 1/2] user-manual: add global config section
From: Jonathan Nieder @ 2009-10-11 22:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> So that users get to know how to configure git from the get-to with good
> practical example (color.ui = auto) that most people would probably like
> anyway.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Good idea. Some comments:
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' (for the user) and 'repository' variables, where
> +'repository' variables take precedence over 'global' ones.
What are these different locations you speak of? If git’s configuration
is complicated to deal with, maybe that is something that could be
improved.
This is very early in the manual, where every word counts. I am not
very good at wording and do not have any better suggestions, but would
it be possible to more efficiently convey this:
Git reads its per-user configuration from ~/.gitignore.
That file can also be manipulated with the "git config"
command, which can be convenient in scripts or when using
operating systems like Windows where it is not clear where
the home directory is.
For example, if your terminal supports it, you can tell Git
to use color in the output for commands such as "git diff"
with "git config --global color.ui auto".
For more information and a list of possible settings, see
git-config(1).
By the way, this reminds me that I am not sure git-config(1) conveys the
list of configuration items in an ideal way. It can be easy to dismiss
that page as plumbing documentation when seeing it for the first time.
Should we ship a sample .gitconfig with all items included and comments
describing them, or a separate gitconfig(5)? Either would be easy to
generate from config.txt.
Thoughts?
Jonathan
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-11 21:12 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, msysgit
In-Reply-To: <be6fef0d0910101554p53d5532cp17768d2c95e9dbf@mail.gmail.com>
Tay Ray Chuan wrote:
> just to check, running
>
> echo list | git remote-curl http://github.com/loudej/spark.git
>
> and
>
> git clone http://github.com/loudej/spark.git
>
> both gives the same error message:
>
> An unhandled win32 exception occurred in git-remote-curl.exe [5820].
> Just-In-Time debugging this exception failed with the following
> error: No installed debugger has Just-In-Time debugging enabled. In
> Visual Studio, Just-In-Time debugging can be enabled from
> Tools/Options/Debugging/Just-In-Time.
>
> Check the documentation index for 'Just-in-time debugging, errors'
> for more information.
>
> in a dialog?
>
>> Is there any way to obtain more information from this crash?
>> Some debug mode?
>
> I'm assuming you're using the Microsoft Visual Studio development
> tools to compile git from the source. I'm cc'ing this to the msysgit
> mailing list, perhaps someone familiar with them can advise you
> further.
>
Git was compiled with msysGit, the errors are generated inside msysGit shell,
and VS2008 debugger gives this message:
"Unhandled exception at 0x00420354 in git-remote-curl.exe:
0xC0000005: Access violation reading location 0x00000000."
Have a nice day,
Eduard
^ permalink raw reply
* [PATCH] Documentation: add 'git replace' to main git manpage
From: SZEDER Gábor @ 2009-10-11 21:08 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
command-list.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/command-list.txt b/command-list.txt
index fb03a2e..59b0adc 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -92,6 +92,7 @@ git-reflog ancillarymanipulators
git-relink ancillarymanipulators
git-remote ancillarymanipulators
git-repack ancillarymanipulators
+git-replace ancillarymanipulators
git-repo-config ancillarymanipulators deprecated
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
--
1.6.5.85.g16dab
^ permalink raw reply related
* [ANN] gitsharp version 0.1.3 released
From: Meinrad Recheis @ 2009-10-11 21:10 UTC (permalink / raw)
To: git
Hello git community,
GitSharp intends to bring best native git support to Windows. So far
the command line interface is still alpha but the library
GitSharp.Core is already quite usable.
Status Report:
Porting of the jgit core is done, we are waiting for the jgit people
to commit something ;). Just kidding, we still need to port some code
from the jgit command line interface and we are working on a hand full
of porting bugs in the core. Some important bugs have been squashed
since the last release:
In a heroic debugging effort Nulltoken fixed the index-bug that made
git# incompatible to the original git. Now we are on track again.
Rolenun fixed git.exe which failed when started on windows via the
system %PATH%.
On top of that, there is a new user centric api which resides in
namespace Git. It simplifies interaction with git objects and
commands, hides the technical complexity of the core and should
provide a stable interface for your applications (once it is done).
The api is still work in progress, so please expect that it will be
changed / improved / extended, until everyone is happy with it. You
can see it in action in the repository browser demo at
http://github.com/henon/GitSharp.Demo
Have fun,
--Henon
^ permalink raw reply
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:56 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00910111353r20de1fb6u2289999491a9310a@mail.gmail.com>
On Sun, Oct 11, 2009 at 11:53 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> "Fix a bunch of pointer declarations".
>
> But in this patch you fixed *only* one pointer declaration:
> struct diffstat_t* data -> struct diffstat_t *data
Yeah, it's a remainder of a patch I sent some time ago. I don't know
why that didn't got picked up =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Thiago Farina @ 2009-10-11 20:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
"Fix a bunch of pointer declarations".
But in this patch you fixed *only* one pointer declaration:
struct diffstat_t* data -> struct diffstat_t *data
^ permalink raw reply
* [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-1-git-send-email-felipe.contreras@gmail.com>
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index e1be189..b39c1b6 100644
--- a/diff.c
+++ b/diff.c
@@ -999,7 +999,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
total_files, adds, dels);
}
-static void show_shortstats(struct diffstat_t* data, struct diff_options *options)
+static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
{
int i, adds = 0, dels = 0, total_files = data->nr;
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..29d7b75 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..42d92fd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1384,7 +1384,7 @@ were merged.
However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
-just performs a "fast forward"; the head of the current branch is moved
+just performs a "fast-forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
@@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-<<fast-forwards,fast forward>>; instead, your branch will just be
+<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The `git pull` command can also be given "." as the "remote" repository,
@@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master
-------------------------------------------------
As with `git fetch`, `git push` will complain if this does not result in a
-<<fast-forwards,fast forward>>; see the following section for details on
+<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
@@ -1976,7 +1976,7 @@ details.
What to do when a push fails
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a push would not result in a <<fast-forwards,fast forward>> of the
+If a push would not result in a <<fast-forwards,fast-forward>> of the
remote branch, then it will fail with an error like:
-------------------------------------------------
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
+changes git will simply do a fast-forward merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
@@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch"
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a <<fast-forwards,fast forward>>.
+commit. Git calls this process a <<fast-forwards,fast-forward>>.
-A fast forward looks something like this:
+A fast-forward looks something like this:
................................................
o--o--o--o <-- old head of the branch
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-1-git-send-email-felipe.contreras@gmail.com>
So that users get to know how to configure git from the get-to with good
practical example (color.ui = auto) that most people would probably like
anyway.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..ff2563a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -40,6 +40,33 @@ without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
+[[getting-started]]
+Getting started
+=============
+
+Git's configuration is distributed among different locations--this manual will
+only to deal with 'global' (for the user) and 'repository' variables, where
+'repository' variables take precedence over 'global' ones.
+
+You would probably want to start setting up something useful:
+------------------------------------------------
+$ git config --global color.ui auto
+------------------------------------------------
+
+This will make prettier the output of certain commands such as `git diff`, but
+that's not important; what is important here is that `color.ui` has been
+stored in the 'global' configuration.
+
+View and manually modify the configuration by opening `~/.gitconfig`:
+------------------------------------------------
+[color]
+ ui = auto
+------------------------------------------------
+
+Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
+
+More git configurations will be covered in the rest of the manual, if you want
+to learn more look at linkgit:git-config[1] for details.
[[repositories-and-branches]]
Repositories and Branches
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/3] Trivial patches
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
These are a bunch of no-brainers. The one for bool types has been discussed and
agreed before.
Felipe Contreras (3):
Fix a bunch of pointer declarations (codestyle)
git config: clarify bool types
user-manual: use 'fast-forward'
Documentation/user-manual.txt | 14 +++++++-------
builtin-config.c | 4 ++--
diff.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/2] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
This is shorter, avoids the burder to think about the format of the
configuration file, and most guides out there prefer this form.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff2563a..bab64f8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1008,13 +1008,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
This basically introduces the "getting started" section so users get familiar
with the configuration from the get-go, and also, most people prefer to teach
'git config --global' to setup the user name and email. Here are a few
examples:
git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
GNOME:
http://live.gnome.org/Git/Developers
SourceForge:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
github:
http://help.github.com/git-email-settings/
Felipe Contreras (2):
user-manual: add global config section
user-manual: simplify the user configuration
Documentation/user-manual.txt | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: git log --graph
From: Jakub Narebski @ 2009-10-11 20:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sverre Rabbelier, Dilip M, git
In-Reply-To: <vpqhbu5zplr.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I personnally like the format of
>
> $ git log --graph --pretty=oneline --abbrev-commit
>
> with ui.color set to true in ~/.gitconfig.
You can use
$ git log --graph --oneline
nowadays for that. A bit shorter.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log --graph
From: Matthieu Moy @ 2009-10-11 19:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dilip M, git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
That said, git log --graph --all will show multiple branches.
I personnally like the format of
git log --graph --pretty=oneline --abbrev-commit
with ui.color set to true in ~/.gitconfig.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-11 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7viqelwyp1.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
> Thanks.
>
> The change looks innocent enough and I do not expect to see any unexpected
> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
> queue this fix and aim for 1.6.5.1.
I think this patch is good to apply, as there is no conceivable reason
to even look at excludes when listing modified files.
But this triggered my spider sense; shouldn't --exclude-standard simply
be a no-op for ls-files when we are not listing untracked files? And
bisecting, it seems that it is a very old regression caused by 63d285c
(per-directory-exclude: lazily read .gitignore files, 2007-11-29).
I don't know if it is worth fixing now or not. It does seem a bit
inconsistent to me (since everything else is very clear that .gitignore
is only about untracked files), but nobody seems to have been
complaining for the last two years (and they may have, in fact, been
coding to the new behavior).
-Peff
^ permalink raw reply
* Re: git svn with non-standard svn layout
From: Fabian Molder @ 2009-10-11 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <20091011070937.GC16264@dcvr.yhbt.net>
Eric Wong <normalperson <at> yhbt.net> writes:
...
>
> Hi Fabian,
>
> Since you don't want to track the entire repo and these seem like
> unrelated (history-wise) trees, you probably want the simplest cases:
>
> git svn clone svn://example.com/path/to/xapplication2
> git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
>
> These commands are like doing the following with plain old svn:
>
> svn co svn://example.com/path/to/xapplication2
> svn co svn://example.com/path/to/aa/bb/cc/xapplication1
>
> > I tried to use "git config svn-remote.svn.branches" to do this,
> > please see in function "do_git_svn" in bash-script - but no success
>
> svn-remote.svn.branches and tags are really only for repos with
> standard layouts.
>
Hello Eric,
hmm, understand,
but this just does an checkout to the working dir
the reason for using git is:
- work offline, with (at least read) access to all the svn branches
- have some more (privat, not commit back to svn) branches for experiments
- all the nice git stuff ..
regards,
Fabian
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Steven Noonan @ 2009-10-11 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pydhk.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Steven Noonan <steven@uplinklabs.net> writes:
>
>> Uh-oh.
>>
>> Alcarin:crisscross steven$ git remote update
>> Updating origin
>> fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
>> git repository
>> fatal: The remote end hung up unexpectedly
>> error: Could not fetch origin
>
> Try user@site:path/to/repo.git with a colon. As you mentioned already,
> you could also use ssh://user@site/full/path/to/repo.git
Oops. You're right, of course. I'm going on 4 hours of sleep in 2
days, so needless to say I'm not at my best right now. Sorry for the
noise.
>
>> The 'ssh://' part is omitted in numerous places on github.com. I
>> realize github.com isn't the final authority on the syntax of the URI,
>
> What do you mean by "final authority"?
I didn't want to imply that "github says to do it this way, so git
should follow".
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-11 18:52 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: git
In-Reply-To: <1255189906-16049-1-git-send-email-pav@iki.fi>
Thanks.
The change looks innocent enough and I do not expect to see any unexpected
regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
queue this fix and aim for 1.6.5.1.
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Junio C Hamano @ 2009-10-11 18:52 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4AD1B6A4.8060405@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> I became aware of this issue while looking into problems occuring
>>> when a user created a branch starting with a '/' in git gui (e.g.
>>> "/foo"). Strange things happen, while git gui shows the current
>>> branch as "/foo" under the hood a branch "foo" (without the slash)
>>> had been created. But then you can't delete "/foo" from git gui,
>>> because a branch of that name doesn't exist.
>>
>> Perhaps an interface to give a cleaned-up version, e.g.
>>
>> $ git check-ref-format --print refs/heads//foo/bar
>> refs/heads/foo/bar
>>
>> is what you want in order to fix git-gui? I dunno.
>
> Yes, one solution could be to fix every application handling branch, tag
> or repo names to mimic the namechange done in the bowels of git. But i
> think it is not worth the hassle.
That cuts both ways.
When the users make typoes (e.g. /foo//bar) you can accept the only sane
correction (e.g. foo/bar) instead of rejecting, since the only thing the
user can do after getting such a rejection is to correct it to that
corrected name (e.g. foo/bar) himself and re-issue the command anyway.
You can push the "hassle" down to the user, or you can fix the tool to
remove the hassle from the user.
Besides, by rejecting what we used to accept you are breaking people's
expectations. So I am moderately negative, unless you can say your "every
application" is literally _tons_.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Junio C Hamano @ 2009-10-11 18:47 UTC (permalink / raw)
To: Steven Noonan; +Cc: git
In-Reply-To: <f488382f0910110930u1af92299ld5d72dbb31ed1914@mail.gmail.com>
Steven Noonan <steven@uplinklabs.net> writes:
> Uh-oh.
>
> Alcarin:crisscross steven$ git remote update
> Updating origin
> fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> error: Could not fetch origin
Try user@site:path/to/repo.git with a colon. As you mentioned already,
you could also use ssh://user@site/full/path/to/repo.git
> The 'ssh://' part is omitted in numerous places on github.com. I
> realize github.com isn't the final authority on the syntax of the URI,
What do you mean by "final authority"?
Your misconfigured URL is diagnosed by the local client on your end and I
do not think it has anything to do with github. Do you mean github.com
documentation primarily uses scp syntax (i.e. [user@]site:path/to/repo)
instead of the fake URI syntax (i.e. ssh://user@site/full/path/to/repo),
*but* misspells the former without colon (i.e. [user@]site/path/to/repo)?
If that is the case, it is something github folks need to fix, but I doubt
they have such a breakage.
> but was this an intentional change or a regression?
I do not think older clients ever allowed your colon-less scp syntax. Do
you really see any *change*? IOW, not the difference between the ssh://
syntax and a misspelled scp syntax, but a difference between versions of
git working and not working with a misspelled scp syntax?
Which version of git worked with "git@github.com/tycho/crisscross.git" for
you?
^ permalink raw reply
* [RFC/PATCH] git: add --no-replace option to disable replacing
From: Christian Couder @ 2009-10-11 15:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace" option that this patch adds it is possible to
get information about the original commit using:
$ git --no-replace cat-file -p N
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Jakub Narebski wrote:
> Wouldn't it be better for this option to be option for git
> wrapper, i.e.
>
> $ git --no-replace cat-file -p N
>
> and not
>
> $ git cat-file --no-replace -p N
You mean something like this patch?
This is untested yet. I will add some tests and documentation
later if it's ok to add this option.
diff --git a/git.c b/git.c
index 9883009..cfef7ac 100644
--- a/git.c
+++ b/git.c
@@ -6,7 +6,7 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]\n"
- " [-p|--paginate|--no-pager]\n"
+ " [-p|--paginate|--no-pager] [--no-replace]\n"
" [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n"
" [--help] COMMAND [ARGS]";
@@ -87,6 +87,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
use_pager = 0;
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-replace")) {
+ read_replace_refs = 0;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
--
1.6.5.1.g31b53
^ permalink raw reply related
* Re: git log --graph
From: Sverre Rabbelier @ 2009-10-11 18:35 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910111127q102aa6a1qc3c0850f8a8a1509@mail.gmail.com>
Heya,
On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
> I am trying git log --graph. (has commits in two branches...). But
> always see one line :(
It'll show you the history of one branch at a time online, you won't
get the demo-ed multiple lines unless the branch you're looking at
contains merges.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git log --graph
From: Dilip M @ 2009-10-11 18:27 UTC (permalink / raw)
To: git
I am using: git version 1.6.3.2
Somehow not getting text graph as mentioned in
http://www.gitready.com/intermediate/2009/01/26/text-based-graph.html
Any hints would really help..
I am trying git log --graph. (has commits in two branches...). But
always see one line :(
--
Dilip
^ permalink raw reply
* ident pattern match is incorrect
From: Bruce Korb @ 2009-10-11 16:52 UTC (permalink / raw)
To: git; +Cc: Bruce Korb
The git attribute "ident" fails here:
sed '2,/and the template file/d
/\$Id:/d
/Last template edit:/d' getopt-test_${testname}.c
The pattern match for ident should be (shell syntax):
$'\$Id(:[^$\n]+\$|\$)'
In other words, it is not a multi-line pattern.
I was looking for a bugzilla entry here:
http://git-scm.com/
but I did not see a bug reporting method.
^ 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