* [StGit PATCH 2/4] Tutorial: Explain diffs a little bit better
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Say that we use unified diffs, and point to the Wikipedia article
about them. We should probably explain this in more detail ourselves
when we get a proper user guide; but for the tutorial, this is
probably enough.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 103f3e4..e9d8b22 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -103,10 +103,11 @@ And voilà -- the patch is no longer empty:
_main()
finally:
-(I'm assuming you're already familiar with patches like this from Git,
-but it's really quite simple; in this example, I've added the +$$print
-'My first patch!'$$+ line to the file +stgit/main.py+, at around line
-171.)
+(I'm assuming you're already familiar with
+htmllink:http://en.wikipedia.org/wiki/Diff#Unified_format[unified
+diff] patches like this from Git, but it's really quite simple; in
+this example, I've added the +$$print 'My first patch!'$$+ line to the
+file +stgit/main.py+, at around line 171.)
Since the patch is also a regular Git commit, you can also look at it
with regular Git tools such as manlink:gitk[].
^ permalink raw reply related
* [StGit PATCH 1/4] Tutorial: Talk about conflicts when introducing StGit
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Conflicts and conflict resolving are essential features of StGit, so
we'd better tell the user about them.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/stg.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index 5973a6b..fc8fd7c 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -38,6 +38,14 @@ to maintain a 'patch stack' on top of a Git branch:
an updated branch, you can take all your patches and apply them on
top of the updated branch.
+ * As you would expect, changing what is below a patch can cause that
+ patch to no longer apply cleanly -- this can occur when you
+ reorder patches, rebase patches, or refresh a non-topmost patch.
+ StGit uses Git's rename-aware three-way merge capability to
+ automatically fix up what it can; if it still fails, it lets you
+ manually resolve the conflict just like you would resolve a merge
+ conflict in Git.
+
* The patch stack is just some extra metadata attached to regular
Git commits, so you can continue to use most Git tools along with
StGit.
^ permalink raw reply related
* [StGit PATCH 0/4] More tutorial updates
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
More updates to the tutorial. I'd really appreciate if people would
sanity check these; a bad tutorial tends to reflect negatively on a
project.
---
Karl Hasselström (4):
Tutorial: Write about rebasing
Tutorial: Cover "stg mail"
Tutorial: Explain diffs a little bit better
Tutorial: Talk about conflicts when introducing StGit
Documentation/stg.txt | 8 ++
Documentation/tutorial.txt | 191 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 191 insertions(+), 8 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Jakub Narebski @ 2008-10-12 15:04 UTC (permalink / raw)
To: git
In-Reply-To: <20081012141952.GD21650@dpotapov.dyndns.org>
Dmitry Potapov wrote:
>> And since its being
>> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
>> also be supported for input termination with NUL instead of LF.
>
> I have added it, but after I did, I start to wonder whether it is the
> right thing to do to unquote NUL terminated input line?
I think that -z should be not quoted (like git-diff-tree or git-ls-tree
_output_); if it is, then IMHO it is a bug.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 14:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Sixt, Alexander Gavrilov, git, Shawn O. Pearce
In-Reply-To: <18671.55733.970601.454074@cargo.ozlabs.ibm.com>
On Sat, Oct 11, 2008 at 09:39:49AM +1100, Paul Mackerras wrote:
>
> Actually, what was done with git diff-tree --stdin was to have it do
> fflush(stdout) when it sees a blank line in the input. That gives the
> calling program a way to get the output up to that point without
> having to do a flush for every line of output.
It is an interesting idea, but I have not seen any other git command
doing so, and my measurement in git repo on Linux have not offered
any noticeable speed-up. So, I am not sure if it is worth it.
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 14:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Alexander Gavrilov, git, Paul Mackerras
In-Reply-To: <20081008152443.GA4795@spearce.org>
On Wed, Oct 08, 2008 at 08:24:43AM -0700, Shawn O. Pearce wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
> > This allows multiple paths to be specified on stdin.
>
> > diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
> > index 2b821f2..0839a57 100644
> > --- a/Documentation/git-check-attr.txt
> > +++ b/Documentation/git-check-attr.txt
> > @@ -9,6 +9,7 @@ git-check-attr - Display gitattributes information.
> > SYNOPSIS
> > --------
> > 'git check-attr' attr... [--] pathname...
> > +'git check-attr' --stdin-paths attr... < <list-of-paths
>
> I wonder if the option should just be "--stdin".
I used "--stdin-paths" because git hash-object uses it, while "--stdin"
means to read the object from standard input. OTOH, we are never going
to read the object from standard input in check-attr and some other git
commands use "--stdin" to mean: read the list of paths from the standard
input. So, I fully agree here.
> And since its being
> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
> also be supported for input termination with NUL instead of LF.
I have added it, but after I did, I start to wonder whether it is the
right thing to do to unquote NUL terminated input line?
NUL terminated makes sense when you feed raw-bytes, and if the first
byte happen to be a quote character, I suppose it should be treated
just as any other byte, not as a sign that the string is quited. But
then I looked at git checkout-index, and it unquotes string even if it
is NUL terminated. I don't think it is the right thing to do, but just
to be consistent, I have decided to leave as-is, i.e. to unquote a NUL
terminated string.
> > +test_expect_success 'attribute test: read paths from stdin' '
>
> A test case for the quoting might also be good.
As far as I can tell, there is no test case for special characters in
filenames when these filenames are given as arguments. And there are a
few problems with them. First, it is using colon as a separator in
output, which breaks parsing of a filename containing colons. Second,
I still have not figured out how to specify filenames with special
characters in gitattributes. The documentation does not say anything
and was lazy to study the code. Does gitattributes understand quote
strings in filenames?
Anyway, here is interdiff to my previous patch, which addresses two
first points as I described above. (I can resend the full patch if
necessary).
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sun, 12 Oct 2008 18:08:43 +0400
Subject: [PATCH] check-attr: Add --stdin option
---
Documentation/git-check-attr.txt | 8 ++++++--
builtin-check-attr.c | 13 +++++++++----
t/t0003-attributes.sh | 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 0839a57..14e4374 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,7 +9,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin-paths attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths
DESCRIPTION
-----------
@@ -18,9 +18,13 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
---stdin-paths::
+--stdin::
Read file names from stdin instead of from the command-line.
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index fa1e4d5..02a8292 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -7,12 +7,16 @@
static int stdin_paths;
static const char * const check_attr_usage[] = {
"git check-attr attr... [--] pathname...",
-"git check-attr --stdin-paths attr... < <list-of-paths>",
+"git check-attr --stdin attr... < <list-of-paths>",
NULL
};
+static int null_term_line;
+
static const struct option check_attr_options[] = {
- OPT_BOOLEAN(0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN(0 , "stdin", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN('z', NULL, &null_term_line,
+ "input paths are terminated by a null character"),
OPT_END()
};
@@ -41,10 +45,11 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
const char** name)
{
struct strbuf buf, nbuf;
+ int line_termination = null_term_line ? 0 : '\n';
strbuf_init(&buf, 0);
strbuf_init(&nbuf, 0);
- while (strbuf_getline(&buf, stdin, '\n') != EOF) {
+ while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
if (buf.buf[0] == '"') {
strbuf_reset(&nbuf);
if (unquote_c_style(&nbuf, buf.buf, NULL))
@@ -90,7 +95,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
if (cnt <= 0)
errstr = "No attribute specified";
else if (stdin_paths && doubledash < argc)
- errstr = "Can't specify files with --stdin-paths";
+ errstr = "Can't specify files with --stdin";
if (errstr) {
error (errstr);
usage_with_options(check_attr_usage, check_attr_options);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f6901b4..1c77192 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -60,7 +60,7 @@ a/b/h: test: a/b/h
a/b/d/g: test: a/b/d/*
EOF
- sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
+ sed -e "s/:.*//" < expect | git check-attr --stdin test > actual &&
test_cmp expect actual
'
--
1.6.0.2.521.g49aa8.dirty
-- >8 --
^ permalink raw reply related
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-12 14:15 UTC (permalink / raw)
To: Wang Chen
Cc: Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F1DF6A.4000900@cn.fujitsu.com>
Wang Chen wrote:
>
> So, the current solutions are:
> 1. Waiting for Shawn fixing it.
> 2. Asking Ingo to "git update-server-info" after each push.
> 3. Murdering our IT people.
>
> I'd rather to do the second solution than the third one :)
>
Actually, the third solution is the proper one given the circumstances
you find yourself in. None of this would be a problem if there wasn't a
bunch of companies with incompetent network management.
-hpa
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-12 14:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012124105.GA26988@elte.hu>
Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
>> Wang Chen wrote:
>>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>>> 1.5.3.x)
>>> My git version is 1.5.5.1, although it doesn't matter ;)
>>>
>> http transport requires that "git update-server-info" is done after
>> each push. Otherwise, it ends up in a trainwreck.
>
> can i simply put "git update-server-info" into .git/hooks/post-receive
> to solve this problem?
>
post-update, rather than post-receive.
The standard post-update.sample contains it, it just needs a rename.
-hpa
^ permalink raw reply
* Re: git status options feature suggestion
From: Andreas Ericsson @ 2008-10-12 13:52 UTC (permalink / raw)
To: Teemu Likonen
Cc: Wincent Colaiuta, Junio C Hamano, Jeff King, Michael J Gruber,
Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <87od1qrqhi.fsf@iki.fi>
Teemu Likonen wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> I think if you're introducing a different command then you should make
>> sure it doesn't happen to be an abbreviation of an existing one. It
>> would be better to give it some other name (info, foo, whatever). If
>> svn people then want to make an "st" alias pointing to it they're free
>> to do so.
>
> In Subversion and Bazaar "info" command gives mostly information about
> the repository itself. They don't talk about individual files at all.
> "status" is the command (also in Mercurial) for getting information
> about the current state of files in the tree.
>
> I think it would be really sad if "git status" can't be extended to
> match people's needs. I don't like the idea of a new name for such
> status command. It's a kind of "why git people always invent new names
> for familiar commands?" thing.
Well, the solution is fairly simple then. Just make it configurable and
set it in your ~/.gitconfig. It's not my itch to scratch though. I
loathe the sparse output from cvs/svn/whatnot and would be just as happy
if I never had to look at it again. I can understand its usefulness for
scripting, but 'git status' is porcelain so for that purpose it really
belongs somewhere else.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Dmitry Potapov @ 2008-10-12 13:50 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Sixt, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <81b0412b0810111558vb69be00if4842fa91d777c3b@mail.gmail.com>
On Sun, Oct 12, 2008 at 12:58:52AM +0200, Alex Riesen wrote:
> 2008/10/11 Dmitry Potapov <dpotapov@gmail.com>:
> >> > + /* On Windows, file names are case-insensitive */
> >> > + case 'G':
> >> > + if ((rest[1]|0x20) != 'i')
> >> > + break;
> >> > + if ((rest[2]|0x20) != 't')
> >> > + break;
> >>
> >> We have tolower().
> >
> > I am aware of that, but I am not sure what we gain by using it. It seems
> > it makes only code bigger and slow.
>
> It does? Care to look into git-compat-util.h?
As a matter of fact, I did, and I see the following:
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
static inline int sane_case(int x, int high)
{
if (sane_istest(x, GIT_ALPHA))
x = (x & ~0x20) | high;
return x;
}
So, it looks like an extra look up and an extra comparison here.
>
> > ... As to readability, I don't see much
> > improvement... Isn't obvious what this code does, especially with the
> > above comment?
>
> You want to seriously argue that "a | 0x20" is as readable as "tolower(a)"?
> For the years to come? With a person who does not even know what ASCII is?
> Ok, I'm exaggerating. But the point is: it is not us who will be
> reading the code.
Obviously, for a person who don't know what ASCII is, tolower() will be
much easier to understand, but the question is what I can reasonable to
expect for a person reading this code later. A similar argument can be
made about adding extra parenthesis, i.e. instead of writing
if (a == b || c == d)
you should always write
if ((a == b) || (c == d))
because some people do not remember the priority of each operator.
(And I have seen such programmers who claim to have many experience of
writing in C, yet, they do not remember operator priority.)
For me, using tolower() does not make it more readable, but maybe I am
too old-fashion assuming that people are supposed to know at least basic
things about ASCII.
> BTW, is it such a critical path?
I am not sure whether it is critical or not. It is called for each
name in path. So, if you have a long path, it may be called quite a
few times per a single path. Also, some operation such 'git add' can
call verify_path() more than once (IIRC, it was called thrice per each
added file). But I have no numbers to tell whether it is noticeable or
not.
> Can't the code be unified and do without #ifdef?
It will impose a extra restriction on what file names people can use,
and I don't like extra restrictions for those who use sane file systems.
Dmitry
^ permalink raw reply
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Dmitry Potapov @ 2008-10-12 13:39 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, git
In-Reply-To: <1223765806-3332-1-git-send-email-mlevedahl@gmail.com>
On Sat, Oct 11, 2008 at 06:56:46PM -0400, Mark Levedahl wrote:
> diff --git a/compat/cygwin.c b/compat/cygwin.c
> index 423ff20..1fed265 100644
> --- a/compat/cygwin.c
> +++ b/compat/cygwin.c
> @@ -91,13 +91,20 @@ static int cygwin_stat(const char *path, struct stat *buf)
> * functions should be used. The choice is determined by core.ignorecygwinfstricks.
> * Reading this option is not always possible immediately as git_dir may be
> * not be set yet. So until it is set, use cygwin lstat/stat functions.
> + * However, if core.filemode is true, we *must* use the Cygwin posix stat as
> + * the Windows stat fuctions do not determine posix filemode.
> */
> static int native_stat = 1;
> +static int core_filemode = 0;
Is it a reason to add a new variable instead of using trust_executable_bit?
And if so, why its default value is different? I know that this default does
not matter usually, because core.filemode is always stored in .git/config,
but still I don't like this discrapency.
Otherwise, I don't have any objection to this patch.
Dmitry
^ permalink raw reply
* [PATCH/RFC] gitweb: Separate features with no project specific override
From: Jakub Narebski @ 2008-10-12 13:05 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis
Put features for which project specific override is not supported into
separate %global_feature hash, updating gitweb_check_feature()
subroutine to use it.
While at it remove stale comment for 'pathinfo' feature; requiring to
use workaround specified was fixed in b65910f (gitweb: remove
PATH_INFO from $my_url and $my_uri).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch has the advantage of clear separation of non-overridable
and overridable features; currently the only difference is lack of
subroutine and comment on feature. For non-overridable features the
complexisty of {'sub'=>..., 'override'=>..., 'default'=>...} is not
needed.
It has the disadvantage of invalidating old gitweb configuration, and
that now there are two sources of gitweb config.
FIX IT: some spurious "HASH.." is printed to STDERR (by my 'run gitweb
from command line' script), which I didn't found yet.
gitweb/gitweb.perl | 59 ++++++++++++++++++++++++----------------------------
1 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6edbe..82068f9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -215,13 +215,6 @@ our %feature = (
'override' => 0,
'default' => ['tgz']},
- # Enable text search, which will list the commits which match author,
- # committer or commit text to a given string. Enabled by default.
- # Project specific override is not supported.
- 'search' => {
- 'override' => 0,
- 'default' => [1]},
-
# Enable grep search, which will list the files in currently selected
# tree containing the given string. Enabled by default. This can be
# potentially CPU-intensive, of course.
@@ -248,6 +241,18 @@ our %feature = (
'sub' => \&feature_pickaxe,
'override' => 0,
'default' => [1]},
+);
+
+our %global_feature = (
+ # feature => [ default options...] (array reference)
+ #
+ # For those features project specific override is not supported.
+ #
+ # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+
+ # Enable text search, which will list the commits which match author,
+ # committer or commit text to a given string. Enabled by default.
+ 'search' => [1],
# Make gitweb use an alternative format of the URLs which can be
# more readable and natural-looking: project name is embedded
@@ -257,16 +262,8 @@ our %feature = (
# generates links.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'pathinfo'}{'default'} = [1];
- # Project specific override is not supported.
-
- # Note that you will need to change the default location of CSS,
- # favicon, logo and possibly other files to an absolute URL. Also,
- # if gitweb.cgi serves as your indexfile, you will need to force
- # $my_uri to contain the script name in your $GITWEB_CONFIG.
- 'pathinfo' => {
- 'override' => 0,
- 'default' => [0]},
+ # $global_feature{'pathinfo'} = [1];
+ 'pathinfo' => [0],
# Make gitweb consider projects in project root subdirectories
# to be forks of existing projects. Given project $projname.git,
@@ -277,11 +274,8 @@ our %feature = (
# to be listed after the main project.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'forks'}{'default'} = [1];
- # Project specific override is not supported.
- 'forks' => {
- 'override' => 0,
- 'default' => [0]},
+ # $global_feature{'forks'} = [1];
+ 'forks' => [0],
# Insert custom links to the action bar of all project pages.
# This enables you mainly to link to third-party scripts integrating
@@ -296,12 +290,9 @@ our %feature = (
# hash base (hb gitweb parameter); %% expands to %.
# To enable system wide have in $GITWEB_CONFIG e.g.
- # $feature{'actions'}{'default'} = [('graphiclog',
+ # $global_feature{'actions'} = [('graphiclog',
# '/git-browser/by-commit.html?r=%n', 'summary')];
- # Project specific override is not supported.
- 'actions' => {
- 'override' => 0,
- 'default' => []},
+ 'actions' => [],
# Allow gitweb scan project content tags described in ctags/
# of project repository, and display the popular Web 2.0-ish
@@ -315,16 +306,20 @@ our %feature = (
# a pretty tag cloud instead of just a list of tags.
# To enable system wide have in $GITWEB_CONFIG
- # $feature{'ctags'}{'default'} = ['path_to_tag_script'];
+ # $global_feature{'ctags'} = ['path_to_tag_script'];
# Project specific override is not supported.
- 'ctags' => {
- 'override' => 0,
- 'default' => [0]},
+ 'ctags' => [0],
);
sub gitweb_check_feature {
- my ($name) = @_;
+ my $name = shift;
+
+ if (exists $global_feature{$name}) {
+ return @{$global_feature{$name}};
+ }
+
return unless exists $feature{$name};
+
my ($sub, $override, @defaults) = (
$feature{$name}{'sub'},
$feature{$name}{'override'},
--
Stacked GIT 0.14.3
git version 1.6.0.2
^ permalink raw reply related
* Re: tip tree clone fail
From: Miklos Vajna @ 2008-10-12 12:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012124105.GA26988@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 243 bytes --]
On Sun, Oct 12, 2008 at 02:41:05PM +0200, Ingo Molnar <mingo@elte.hu> wrote:
> can i simply put "git update-server-info" into .git/hooks/post-receive
> to solve this problem?
Yes. And don't forget the chmod +x it, if it's not done yet.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 12:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48EF7BC1.4000401@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> Wang Chen wrote:
>>>
>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>> 1.5.3.x)
>>
>> My git version is 1.5.5.1, although it doesn't matter ;)
>>
>
> http transport requires that "git update-server-info" is done after
> each push. Otherwise, it ends up in a trainwreck.
can i simply put "git update-server-info" into .git/hooks/post-receive
to solve this problem?
Ingo
^ permalink raw reply
* Re: tip tree clone fail
From: Lars Hjemli @ 2008-10-12 12:04 UTC (permalink / raw)
To: Wang Chen
Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F1DF6A.4000900@cn.fujitsu.com>
On Sun, Oct 12, 2008 at 13:28, Wang Chen <wangchen@cn.fujitsu.com> wrote:
>
> H. Peter Anvin said the following on 2008-10-10 23:58:
> > Wang Chen wrote:
> >>>
> >>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
> >>> 1.5.3.x)
> >>
> >> My git version is 1.5.5.1, although it doesn't matter ;)
> >>
> >
> > http transport requires that "git update-server-info" is done after each
> > push. Otherwise, it ends up in a trainwreck.
> >
> > Shawn Pierce at Google is working on a long-term solution, but in the
> > meantime, if you have to use http transport, murder your IT people.
> >
>
>
> So, the current solutions are:
> 1. Waiting for Shawn fixing it.
> 2. Asking Ingo to "git update-server-info" after each push.
> 3. Murdering our IT people.
4. Install cgit, which removes the need for `git update-server-info`
--
larsh
^ permalink raw reply
* Re: git status options feature suggestion
From: Teemu Likonen @ 2008-10-12 11:40 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Junio C Hamano, Jeff King, Michael J Gruber, Johannes Schindelin,
Caleb Cushing, git
In-Reply-To: <971DCAD3-3274-4507-AE3D-5BDCEDB8513C@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I think if you're introducing a different command then you should make
> sure it doesn't happen to be an abbreviation of an existing one. It
> would be better to give it some other name (info, foo, whatever). If
> svn people then want to make an "st" alias pointing to it they're free
> to do so.
In Subversion and Bazaar "info" command gives mostly information about
the repository itself. They don't talk about individual files at all.
"status" is the command (also in Mercurial) for getting information
about the current state of files in the tree.
I think it would be really sad if "git status" can't be extended to
match people's needs. I don't like the idea of a new name for such
status command. It's a kind of "why git people always invent new names
for familiar commands?" thing.
^ permalink raw reply
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-12 11:28 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Thomas Gleixner, Ingo Molnar, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48EF7BC1.4000401@zytor.com>
H. Peter Anvin said the following on 2008-10-10 23:58:
> Wang Chen wrote:
>>>
>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>> 1.5.3.x)
>>
>> My git version is 1.5.5.1, although it doesn't matter ;)
>>
>
> http transport requires that "git update-server-info" is done after each
> push. Otherwise, it ends up in a trainwreck.
>
> Shawn Pierce at Google is working on a long-term solution, but in the
> meantime, if you have to use http transport, murder your IT people.
>
So, the current solutions are:
1. Waiting for Shawn fixing it.
2. Asking Ingo to "git update-server-info" after each push.
3. Murdering our IT people.
I'd rather to do the second solution than the third one :)
Ingo, will you do "git update-server-info" after each push before
Shawn fix this problem?
^ permalink raw reply
* [PATCH] Documentation: remove stale howto/rebase-and-edit.txt
From: Thomas Rast @ 2008-10-12 11:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
The "rebase and edit" howto predates the much easier solution 'git
rebase -i' by two years.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/howto/rebase-and-edit.txt | 79 -------------------------------
1 files changed, 0 insertions(+), 79 deletions(-)
diff --git a/Documentation/howto/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt
deleted file mode 100644
index 554909f..0000000
--- a/Documentation/howto/rebase-and-edit.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
-From: Linus Torvalds <torvalds@osdl.org>
-To: Steve French <smfrench@austin.rr.com>
-cc: git@vger.kernel.org
-Subject: Re: sending changesets from the middle of a git tree
-Abstract: In this article, Linus demonstrates how a broken commit
- in a sequence of commits can be removed by rewinding the head and
- reapplying selected changes.
-
-On Sat, 13 Aug 2005, Linus Torvalds wrote:
-
-> That's correct. Same things apply: you can move a patch over, and create a
-> new one with a modified comment, but basically the _old_ commit will be
-> immutable.
-
-Let me clarify.
-
-You can entirely _drop_ old branches, so commits may be immutable, but
-nothing forces you to keep them. Of course, when you drop a commit, you'll
-always end up dropping all the commits that depended on it, and if you
-actually got somebody else to pull that commit you can't drop it from
-_their_ repository, but undoing things is not impossible.
-
-For example, let's say that you've made a mess of things: you've committed
-three commits "old->a->b->c", and you notice that "a" was broken, but you
-want to save "b" and "c". What you can do is
-
- # Create a branch "broken" that is the current code
- # for reference
- git branch broken
-
- # Reset the main branch to three parents back: this
- # effectively undoes the three top commits
- git reset HEAD^^^
- git checkout -f
-
- # Check the result visually to make sure you know what's
- # going on
- gitk --all
-
- # Re-apply the two top ones from "broken"
- #
- # First "parent of broken" (aka b):
- git-diff-tree -p broken^ | git-apply --index
- git commit --reedit=broken^
-
- # Then "top of broken" (aka c):
- git-diff-tree -p broken | git-apply --index
- git commit --reedit=broken
-
-and you've now re-applied (and possibly edited the comments) the two
-commits b/c, and commit "a" is basically gone (it still exists in the
-"broken" branch, of course).
-
-Finally, check out the end result again:
-
- # Look at the new commit history
- gitk --all
-
-to see that everything looks sensible.
-
-And then, you can just remove the broken branch if you decide you really
-don't want it:
-
- # remove 'broken' branch
- git branch -d broken
-
- # Prune old objects if you're really really sure
- git prune
-
-And yeah, I'm sure there are other ways of doing this. And as usual, the
-above is totally untested, and I just wrote it down in this email, so if
-I've done something wrong, you'll have to figure it out on your own ;)
-
- Linus
--
-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
--
tg: (e782e12..) t/doc-remove-old-howto (depends on: spearce/master)
^ permalink raw reply related
* Re: git status options feature suggestion
From: Wincent Colaiuta @ 2008-10-12 10:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Michael J Gruber, Johannes Schindelin, Caleb Cushing,
git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
El 12/10/2008, a las 8:41, Junio C Hamano escribió:
> Jeff King <peff@peff.net> writes:
>
>> So I think it is probably reasonable to think about a new command
>> (which
>> would not be called status) that shows this information.
>
> I was going to suggest the same. "git st" for people who come from
> "svn st"
> so that "git status" can be kept as traditional "preview of 'git
> commit'".
>
> And just make it mimic whatever folks accustomed to "svn st" would
> expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to
> show
> difference between (HEAD, worktree) while at it.
One of the first aliases I set up when I started using git was "st"
for status, and I'd imagine that's a pretty common thing for people
coming from other SCMs like svn and cvs. But I very quickly became
used to git's notion of what "status" means and I wouldn't want "git
st" to start giving me a different behaviour.
I think if you're introducing a different command then you should make
sure it doesn't happen to be an abbreviation of an existing one. It
would be better to give it some other name (info, foo, whatever). If
svn people then want to make an "st" alias pointing to it they're free
to do so.
Just my 2c.
Cheers,
Wincent
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Leo Razoumov @ 2008-10-12 10:09 UTC (permalink / raw)
To: git
On 10/12/08, Junio C Hamano <gitster@pobox.com> wrote:
> [..snip..]
> I was going to suggest the same. "git st" for people who come from "svn st"
> so that "git status" can be kept as traditional "preview of 'git commit'".
>
> And just make it mimic whatever folks accustomed to "svn st" would expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to show
> difference between (HEAD, worktree) while at it.
>
> And no, I have not seen any argument good enough to change ls-files nor
> diff-$lowlevel output and break people's existing scripts.
>
Please, at least introduce a new option (--status-letters) that makes
git log --name-status
git diff --name-status
git ls-files -v
to use consistent letters to indicate the status. For details, see
recent discussion
http://www.spinics.net/lists/git/msg81141.html
Thanks,
--Leo--
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Junio C Hamano @ 2008-10-12 9:58 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <20081012082607.GA17852@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, in case anybody is interested, here is the patch. Like I said, I
> think we are better off with an alternative to "status", but maybe this
> is useful to somebody anyway.
>
> ---
> diff --git a/builtin-commit.c b/builtin-commit.c
> index b01ad9f..8951364 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -217,7 +217,8 @@ static void create_base_index(void)
> exit(128); /* We've already reported the error, finish dying */
> }
>
> -static char *prepare_index(int argc, const char **argv, const char *prefix)
> +static char *prepare_index(int argc, const char **argv, const char *prefix,
> + int status_only)
> {
> int fd;
> struct string_list partial;
> @@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
> * We still need to refresh the index here.
> */
> if (!pathspec || !*pathspec) {
> - fd = hold_locked_index(&index_lock, 1);
> + fd = hold_locked_index(&index_lock, 0);
> + if (fd < 0) {
> + if (!status_only)
> + die("unable to lock index: %s",
> + strerror(errno));
> + return get_index_file();
> + }
> refresh_cache(REFRESH_QUIET);
You would probably want to refresh_cache() here even if you are not going
to write the resulting index out, so that you won't show the stat-only
differences to the end user. Other than that, I think this is a good
change.
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jakub Narebski @ 2008-10-12 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> So I think it is probably reasonable to think about a new command (which
>> would not be called status) that shows this information.
>
> I was going to suggest the same. "git st" for people who come from "svn st"
> so that "git status" can be kept as traditional "preview of 'git commit'".
Or "git inspect". Or "git info".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-12 8:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Caleb Cushing, git, Junio C Hamano
In-Reply-To: <20081012044900.GA27845@coredump.intra.peff.net>
On Sun, Oct 12, 2008 at 12:49:00AM -0400, Jeff King wrote:
> A week or two ago I came across yet another git-status annoyance: it
> needs write access to the repository to run (I was helping somebody with
> a task on a shared box, and I wanted to run status in their repository
> using my account).
>
> I considered submitting a patch to fix this, but I think it is really
> more fundamental. I use status to get an overview of what's going on in
> a repo, but it is intimately related to a potential commit.
BTW, in case anybody is interested, here is the patch. Like I said, I
think we are better off with an alternative to "status", but maybe this
is useful to somebody anyway.
---
diff --git a/builtin-commit.c b/builtin-commit.c
index b01ad9f..8951364 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -217,7 +217,8 @@ static void create_base_index(void)
exit(128); /* We've already reported the error, finish dying */
}
-static char *prepare_index(int argc, const char **argv, const char *prefix)
+static char *prepare_index(int argc, const char **argv, const char *prefix,
+ int status_only)
{
int fd;
struct string_list partial;
@@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
* We still need to refresh the index here.
*/
if (!pathspec || !*pathspec) {
- fd = hold_locked_index(&index_lock, 1);
+ fd = hold_locked_index(&index_lock, 0);
+ if (fd < 0) {
+ if (!status_only)
+ die("unable to lock index: %s",
+ strerror(errno));
+ return get_index_file();
+ }
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
@@ -869,7 +876,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
argc = parse_and_validate_options(argc, argv, builtin_status_usage, prefix);
- index_file = prepare_index(argc, argv, prefix);
+ index_file = prepare_index(argc, argv, prefix, 1);
commitable = run_status(stdout, index_file, prefix, 0);
@@ -953,7 +960,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
argc = parse_and_validate_options(argc, argv, builtin_commit_usage, prefix);
- index_file = prepare_index(argc, argv, prefix);
+ index_file = prepare_index(argc, argv, prefix, 0);
/* Set up everything for writing the commit object. This includes
running hooks, writing the trees, and interacting with the user. */
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Junio C Hamano @ 2008-10-12 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <20081012064512.GA32597@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?
Sorry, I don't.
> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
>
> A M foo
>
> to show that "foo" has been added since the last commit, but there are
> modifications in the working tree that have not yet been staged.
One thing to keep in mind is what to do when you would want to detect
renames. The parallel walk would be Ok but between HEAD and index there
could be renames involved, and at that point it would get quite tricky.
Once the index is in-core, I think it hurts us much to walk HEAD vs index
and index vs working tree in separate passes.
I think it is perfectly fine to run the diff-index first, and keep the
result from it in a string_list, and then run "diff-files" and annotate
the string_list with the output from it.
Something like...
struct git_st_data {
const char *head_path;
char head_to_index_status;
char index_to_worktree_status;
};
static int cmp_head_path(const void *a_, const void *b_)
{
struct git_st_data *a = (struct git_st_data *)a_;
struct git_st_data *b = (struct git_st_data *)b_;
return strcmp(a->head_path, b->head_path);
}
static void git_st_inspect_index_cb(struct diff_queue_struct *q,
struct diff_options *opts, void *data)
{
struct string_list *git_st_list = data;
int i;
for (i = 0; i < q->nr; i++) {
struct git_st_data *d;
struct string_list_item *e;
struct diff_filepair *fp = &q->queue[i];
d = xcalloc(1, sizeof(*d));
d->head_path = xstrdup(fp->one->path);
e = string_list_insert(fp->two->path, git_st_list);
e->util = d;
d->head_to_index_status = fp->status;
}
}
static void git_st_inspect_file_cb(struct diff_queue_struct *q,
struct diff_options *opts, void *data)
{
struct string_list *git_st_list = data;
int i;
for (i = 0; i < q->nr; i++) {
struct git_st_data *d;
struct string_list_item *e;
struct diff_filepair *fp = &q->queue[i];
e = string_list_lookup(fp->one->path, git_st_list);
if (!e)
die("Oops -- shouldn't happen");
d = e->util;
d->index_to_worktree_status = fp->status;
}
}
void git_st_inspect(struct string_list *git_st_list)
{
struct rev_info rev;
git_st_list->items = NULL;
git_st_list->nr = git_st_list->alloc = 0;
git_st_list->strdup_strings = 1;
/*
* run "diff-index -B -M HEAD" and keep the result in a
* string list, keyed by the path in the index.
*/
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, "HEAD");
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = git_st_inspect_index_cb;
rev.diffopt.format_callback_data = git_st_list;
rev.diffopt.detect_rename = 1;
rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
run_diff_index(&rev, 1);
/*
* run "diff-files" and update the previous with the result.
*/
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = git_st_inspect_file_cb;
rev.diffopt.format_callback_data = git_st_list;
run_diff_files(&rev, 0);
/*
* sort the string-list entries in HEAD path order
*/
qsort(git_st_list->items, git_st_list->nr,
sizeof(struct string_list_item),
cmp_head_path);
}
Then git_st_inspect() can also be called by wt_status_print(), making it
unnecessary to do the equivalent of the above in wt_status_print_updated()
and wt_status_print_changed().
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Jeff King @ 2008-10-12 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Johannes Schindelin, Caleb Cushing, git
In-Reply-To: <7vwsgegvsh.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:
> And just make it mimic whatever folks accustomed to "svn st" would expect,
> modulo we would need two status letters to signal difference between
> (HEAD, index), and (index, worktree). Perhaps three if you want to show
> difference between (HEAD, worktree) while at it.
I remember a long time ago you started on a parallel diff walker that
could diff the working tree, the index, and a tree at once. Do you
remember the issues with it?
I think that would be the right tool here to show each file only once,
but with multiple status flags. Something like:
A M foo
to show that "foo" has been added since the last commit, but there are
modifications in the working tree that have not yet been staged.
-Peff
^ 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