* Re: Add 'sane' mode to 'git reset'
From: Linus Torvalds @ 2008-12-01 18:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <32541b130812010944k3dd825e4pfa8c270ecc75d539@mail.gmail.com>
On Mon, 1 Dec 2008, Avery Pennarun wrote:
>
> For reference, I advised someone just yesterday to use "git reset
> HEAD^" to undo an accidental "commit -a" instead of just "commit".
Yeah, I guess the --mixed default of "git reset" is occasionally useful.
> Also, as far as I know, "git reset HEAD filename" is the only
> recommended way to undo an accidental "git add".
The path-name based ones are actually a totally different animal than the
non-pathname version of "git reset". With pathnames, it won't change the
actual HEAD, so it's really a totally different class of command, just
sharing a name.
But:
> How about calling it --merge instead? That's really what it does:
> merges the diffs from (your current index) to (the requested index)
> into (your working tree and your index).
Sure, "git reset --merge" would probably be a fine form.
Linus
^ permalink raw reply
* Re: Add 'sane' mode to 'git reset'
From: Jakub Narebski @ 2008-12-01 18:04 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130812010944k3dd825e4pfa8c270ecc75d539@mail.gmail.com>
Avery Pennarun wrote:
> On Mon, Dec 1, 2008 at 12:30 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> So add this kind of mode to "git reset", and since it's probably the
>> sanest form of reset (it will not throw any state away), just call it
>> that: "git reset --sane". It should probably be the default, but we likely
>> cannot change the semantics of a regular "git reset", even though it is
>> unlikely that very many people really use the current (insane) default
>> mode of "--mixed" that only resets the index.
[...]
> How about calling it --merge instead? That's really what it does:
> merges the diffs from (your current index) to (the requested index)
> into (your working tree and your index).
I like it, because it is similar to how "git checkout --merge" works.
> Or --keep, because it keeps your working tree changes.
That is also better than --sane...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Jakub Narebski @ 2008-12-01 18:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <200811171140.45884.jnareb@gmail.com>
Use new insert_file() subroutine to insert HTML chunks from external
files: $site_header, $home_text (by default indextext.html),
$site_footer, and $projectroot/$project/REAME.html.
All non-ASCII chars of those files will be broken by Perl IO layer
without decoding to utf8, so insert_file() does to_utf8() on each
printed line; alternate solution would be to open those files with
"binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
Note that inserting README.html lost one of checks for simplicity.
Noticed-by: Tatsuki Sugiura <sugi@nemui.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is more complete solution that the one provided by Tatsuki Sugiura
in original patch
[PATCH] gitweb: fix encode handling for site_{header,footer}
Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
http://thread.gmane.org/gmane.comp.version-control.git/101199
but it is in principle the same solution.
I think this one as it is a bugfix should go in git 1.6.1
gitweb/gitweb.perl | 33 +++++++++++++++++----------------
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..82262a3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2740,6 +2740,15 @@ sub get_file_owner {
return to_utf8($owner);
}
+# assume that file exists
+sub insert_file {
+ my $filename = shift;
+
+ open my $fd, '<', $filename;
+ print map(to_utf8, <$fd>);
+ close $fd;
+}
+
## ......................................................................
## mimetype related functions
@@ -2928,9 +2937,7 @@ EOF
"<body>\n";
if (-f $site_header) {
- open (my $fd, $site_header);
- print <$fd>;
- close $fd;
+ insert_file($site_header);
}
print "<div class=\"page_header\">\n" .
@@ -3017,9 +3024,7 @@ sub git_footer_html {
print "</div>\n"; # class="page_footer"
if (-f $site_footer) {
- open (my $fd, $site_footer);
- print <$fd>;
- close $fd;
+ insert_file($site_footer);
}
print "</body>\n" .
@@ -4358,9 +4363,7 @@ sub git_project_list {
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
- open (my $fd, $home_text);
- print <$fd>;
- close $fd;
+ insert_file($home_text);
print "</div>\n";
}
print $cgi->startform(-method => "get") .
@@ -4472,13 +4475,11 @@ sub git_summary {
print "</table>\n";
if (-s "$projectroot/$project/README.html") {
- if (open my $fd, "$projectroot/$project/README.html") {
- print "<div class=\"title\">readme</div>\n" .
- "<div class=\"readme\">\n";
- print $_ while (<$fd>);
- print "\n</div>\n"; # class="readme"
- close $fd;
- }
+ print "<div class=\"title\">readme</div>\n" .
+ "<div class=\"readme\">\n";
+ insert_file("$projectroot/$project/README.html");
+ print "\n</div>\n"; # class="readme"
+ close $fd;
}
# we need to request one more than 16 (0..15) to check if
^ permalink raw reply related
* Re: Add 'sane' mode to 'git reset'
From: Avery Pennarun @ 2008-12-01 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812010908120.3256@nehalem.linux-foundation.org>
On Mon, Dec 1, 2008 at 12:30 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So add this kind of mode to "git reset", and since it's probably the
> sanest form of reset (it will not throw any state away), just call it
> that: "git reset --sane". It should probably be the default, but we likely
> cannot change the semantics of a regular "git reset", even though it is
> unlikely that very many people really use the current (insane) default
> mode of "--mixed" that only resets the index.
For reference, I advised someone just yesterday to use "git reset
HEAD^" to undo an accidental "commit -a" instead of just "commit".
Also, as far as I know, "git reset HEAD filename" is the only
recommended way to undo an accidental "git add". (Which I do
sometimes when I meant to write "git add -p".) Those two options are
pretty common, I think, and are also perfectly "sane".
How about calling it --merge instead? That's really what it does:
merges the diffs from (your current index) to (the requested index)
into (your working tree and your index).
Or --keep, because it keeps your working tree changes.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jeff King @ 2008-12-01 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228140775-29212-6-git-send-email-gitster@pobox.com>
On Mon, Dec 01, 2008 at 06:12:54AM -0800, Junio C Hamano wrote:
> + packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
> + 0, capabilities, 0, target);
Yuck. My two complaints are:
(1) this implicitly handles only the HEAD symref. I don't think any
others are in common use, but the rest of git handles arbitrary
symrefs just fine. It would be a shame to needlessly limit the
protocol. Can we at least make it <ref>:<ref> to allow later
expansion to other symrefs?
(1a) As a follow-on to that, because the client is not requesting
anything, how would we ask for other symrefs if we want to do so
later? I think it would be nice to eventually allow copying of
arbitrary symrefs within the refs/* hierarchy (e.g.,
project-specific branch aliases). Sending all symrefs right off
the bat is potentially large and wasteful.
(2) You've used up the first such expansion slot forever. Now it's "if
I want to tell you the symref, there is an extra slot, and
otherwise none". But if we ever want to use the _next_ slot, then
you will always have to send this slot (blank, I guess?). It gets
even more complicated if you ever want to an arbitrary number of
symref mappings. Maybe a short header to say "this slot contains a
symref target"?
So (1) and (2) together would make it something like:
<capabilities>\0
symref HEAD:refs/heads/master\0
symref refs/heads/alias:refs/heads/branch\n
which would make adding any new features in the expansion slots easier.
But that still doesn't address (1a). I really like the other proposal a
lot better.
-Peff
^ permalink raw reply
* Re: Is rebase always destructive?
From: Csaba Henk @ 2008-12-01 17:37 UTC (permalink / raw)
To: git
In-Reply-To: <20081201121140.GB32415@mail.local.tull.net>
On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
> On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
>> I can't see any option for rebase which would yield this cp-like
>> behaviour. Am I missing something?
>
> How about this:
>
> git checkout topic
> git branch keepme
> git rebase master
OK, thanks guys, now I'm enlightened (a little bit more than before).
Regards,
Csaba
^ permalink raw reply
* [PATCH (GITK) v2] gitk: Make line origin search update the busy status.
From: Alexander Gavrilov @ 2008-12-01 17:30 UTC (permalink / raw)
To: Git Mailing List; +Cc: Paul Mackerras
Currently the 'show origin of this line' feature does
not update the status field of the gitk window, so it
is not evident that any processing is going on. It may
seem at first that clicking the item had no effect.
This commit adds calls to set and clear the busy
status with an appropriate title, similar to other
search commands.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I changed the visible message to Searching.
I think that this is something of a usability bug, so this
probably should still go in 1.6.1.
Alexander
gitk | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 6eaeadf..076f036 100755
--- a/gitk
+++ b/gitk
@@ -3407,6 +3407,7 @@ proc show_line_source {} {
error_popup [mc "Couldn't start git blame: %s" $err]
return
}
+ nowbusy blaming [mc "Searching"]
fconfigure $f -blocking 0
set i [reg_instance $f]
set blamestuff($i) {}
@@ -3420,6 +3421,7 @@ proc stopblaming {} {
if {[info exists blameinst]} {
stop_instance $blameinst
unset blameinst
+ notbusy blaming
}
}
@@ -3434,6 +3436,7 @@ proc read_line_source {fd inst} {
}
unset commfd($inst)
unset blameinst
+ notbusy blaming
fconfigure $fd -blocking 1
if {[catch {close $fd} err]} {
error_popup [mc "Error running git blame: %s" $err]
--
1.6.0.4.30.gf4240
^ permalink raw reply related
* Add 'sane' mode to 'git reset'
From: Linus Torvalds @ 2008-12-01 17:30 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it's probably the
sanest form of reset (it will not throw any state away), just call it
that: "git reset --sane". It should probably be the default, but we likely
cannot change the semantics of a regular "git reset", even though it is
unlikely that very many people really use the current (insane) default
mode of "--mixed" that only resets the index.
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --sane, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--sane" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --sane reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --sane' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --sane" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 9514b77..05c176d 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -20,11 +20,14 @@
#include "parse-options.h"
static const char * const git_reset_usage[] = {
- "git reset [--mixed | --soft | --hard] [-q] [<commit>]",
+ "git reset [--mixed | --soft | --hard | --sane] [-q] [<commit>]",
"git reset [--mixed] <commit> [--] <paths>...",
NULL
};
+enum reset_type { MIXED, SOFT, HARD, SANE, NONE };
+static const char *reset_type_names[] = { "mixed", "soft", "hard", "sane", NULL };
+
static char *args_to_str(const char **argv)
{
char *buf = NULL;
@@ -49,7 +52,7 @@ static inline int is_merge(void)
return !access(git_path("MERGE_HEAD"), F_OK);
}
-static int reset_index_file(const unsigned char *sha1, int is_hard_reset, int quiet)
+static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet)
{
int i = 0;
const char *args[6];
@@ -57,9 +60,17 @@ static int reset_index_file(const unsigned char *sha1, int is_hard_reset, int qu
args[i++] = "read-tree";
if (!quiet)
args[i++] = "-v";
- args[i++] = "--reset";
- if (is_hard_reset)
+ switch (reset_type) {
+ case SANE:
args[i++] = "-u";
+ args[i++] = "-m";
+ break;
+ case HARD:
+ args[i++] = "-u";
+ /* fallthrough */
+ default:
+ args[i++] = "--reset";
+ }
args[i++] = sha1_to_hex(sha1);
args[i] = NULL;
@@ -169,9 +180,6 @@ static void prepend_reflog_action(const char *action, char *buf, size_t size)
warning("Reflog action message too long: %.*s...", 50, buf);
}
-enum reset_type { MIXED, SOFT, HARD, NONE };
-static const char *reset_type_names[] = { "mixed", "soft", "hard", NULL };
-
int cmd_reset(int argc, const char **argv, const char *prefix)
{
int i = 0, reset_type = NONE, update_ref_status = 0, quiet = 0;
@@ -186,6 +194,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
OPT_SET_INT(0, "soft", &reset_type, "reset only HEAD", SOFT),
OPT_SET_INT(0, "hard", &reset_type,
"reset HEAD, index and working tree", HARD),
+ OPT_SET_INT(0, "sane", &reset_type,
+ "reset HEAD, index and working tree", SANE),
OPT_BOOLEAN('q', NULL, &quiet,
"disable showing new HEAD in hard reset and progress message"),
OPT_END()
@@ -266,7 +276,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (is_merge() || read_cache() < 0 || unmerged_cache())
die("Cannot do a soft reset in the middle of a merge.");
}
- else if (reset_index_file(sha1, (reset_type == HARD), quiet))
+ else if (reset_index_file(sha1, reset_type, quiet))
die("Could not reset index file to revision '%s'.", rev);
/* Any resets update HEAD to the head being switched to,
^ permalink raw reply related
* [PATCH] Modified the default git help message to be grouped by topic
From: Scott Chacon @ 2008-12-01 17:30 UTC (permalink / raw)
To: git; +Cc: gitster
It's difficult to process 21 commands (which is what is output
by default for git when no command is given). I've re-grouped
them into 4 groups of 5 or 6 commands each, which I think is
clearer and easier for new users to process.
As discussed at the GitTogether.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
This makes the 'git' (with no arguments) command look like this:
http://gist.github.com/20553
This won't automatically update with the common-commands.txt file,
but I think it is easier to parse for the command you may be looking
for.
builtin-help.c | 42 +++++++++++++++++++++++++++++-------------
1 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..562d5d1 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -277,19 +277,35 @@ static struct cmdnames main_cmds, other_cmds;
void list_common_cmds_help(void)
{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
- }
+ puts("The most commonly used git commands are:\n\
+\n\
+Basic Commands\n\
+ init Create an empty git repository or reinitialize an existing one\n\
+ add Add file contents to the staging area\n\
+ status Show the working tree and staging area status\n\
+ commit Record changes in the staging area to the repository\n\
+ rm Remove files from the working tree and from the index\n\
+ mv Move or rename a file, a directory, or a symlink\n\
+\n\
+History Commands\n\
+ log Show commit log history\n\
+ diff Show changes between commits, commit and working tree, etc\n\
+ grep Print lines in git tracked files matching a pattern\n\
+ reset Reset current HEAD to the specified state\n\
+ show Show various types of objects\n\
+\n\
+Branch Commands\n\
+ checkout Checkout a branch or paths to the working tree\n\
+ branch List, create, or delete branches\n\
+ merge Join two or more development histories together\n\
+ rebase Apply changes introduced in one branch onto another\n\
+ tag Create, list, delete or verify a tag object signed with GPG\n\
+\n\
+Remote Commands\n\
+ clone Clone a repository into a new directory\n\
+ fetch Download objects and refs from another repository\n\
+ pull Fetch from and merge with another repository or a local branch\n\
+ push Update remote refs along with associated objects");
}
static int is_git_command(const char *s)
--
1.6.0.8.gc9c8
^ permalink raw reply related
* [PATCH] added a built-in alias for 'stage' to the 'add' command
From: Scott Chacon @ 2008-12-01 17:29 UTC (permalink / raw)
To: git; +Cc: gitster
this comes from conversation at the GitTogether where we thought it would
be helpful to be able to teach people to 'stage' files because it tends
to cause confusion when told that they have to keep 'add'ing them.
This continues the movement to start referring to the index as a
staging area (eg: the --staged alias to 'git diff'). Also added a
doc file for 'git stage' that basically points to the docs for
'git add'.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
Documentation/git-stage.txt | 21 +++++++++++++++++++++
git.c | 1 +
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-stage.txt
diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt
new file mode 100644
index 0000000..0640198
--- /dev/null
+++ b/Documentation/git-stage.txt
@@ -0,0 +1,21 @@
+git-stage(1)
+==============
+
+NAME
+----
+git-stage - Add file contents to the staging area
+
+
+SYNOPSIS
+--------
+[verse]
+'git stage' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+ [--all | [--update | -u]] [--intent-to-add | -N]
+ [--refresh] [--ignore-errors] [--] <filepattern>...
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-add[1]. Please refer to the
+documentation of that command.
diff --git a/git.c b/git.c
index 89feb0b..9e5813c 100644
--- a/git.c
+++ b/git.c
@@ -266,6 +266,7 @@ static void handle_internal_command(int argc, const char **argv)
const char *cmd = argv[0];
static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
+ { "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
--
1.6.0.8.gc9c8
^ permalink raw reply related
* [PATCH (GITK FIX)] gitk: Fix the "notflag: no such variable" error in --not processing.
From: Alexander Gavrilov @ 2008-12-01 17:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <49341101.8050400@viscovery.net>
Commit 2958228430b63f2e38c55519d1f98d8d6d9e23f3 fixed the
switch statement used in option processing, which made some of
the previously unreachable cases executable. This uncovered the
fact that the variable used in the handling of the --not option is not
initialized.
This patch initializes it. Note that actually it is also possible to
remove it completely, because currently nobody uses the value.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
On Monday 01 December 2008 19:29:53 Johannes Sixt wrote:
> > $ git bisect view
> > Error in startup script: can't read "notflag": no such variable
> > while executing
> > "expr {!$notflag}"
> > ("--not" arm line 2)
> > invoked from within
> > "switch -glob -- $arg {
> > "-d" -
> > "--date-order" {
> > set vdatemode($n) 1
> > # remove from origargs in case we hit an unknown option
> > set origarg..."
> > (procedure "parseviewargs" line 21)
> > invoked from within
> > "parseviewargs $view $args"
> > (procedure "start_rev_list" line 27)
> > invoked from within
> > "start_rev_list $curview"
> > (procedure "getcommits" line 5)
> > invoked from within
> > "getcommits {}"
> > (file "/usr/local/bin/gitk" line 10897)
>
> Bisection points to this commit:
>
> commit 2958228430b63f2e38c55519d1f98d8d6d9e23f3
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index f7f1776..6eaeadf 100755
--- a/gitk
+++ b/gitk
@@ -139,6 +139,7 @@ proc parseviewargs {n arglist} {
set origargs $arglist
set allknown 1
set filtered 0
+ set notflag 0
set i -1
foreach arg $arglist {
incr i
--
1.6.0.4.30.gf4240
^ permalink raw reply related
* Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed
From: Matt McCutchen @ 2008-12-01 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr64yfexp.fsf@gitster.siamese.dyndns.org>
On Wed, 2008-11-26 at 11:46 -0800, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> > I think it's unnecessary to warn that the checkout has been forced due to an
> > unborn current branch if -f has been explicitly passed. For one project, I am
> > using git-new-workdir to create workdirs from a bare repository whose HEAD is
> > set to an unborn branch, and this warning started to irritate me.
>
> I doubt anybody minds this particular change per-se, but I wonder what the
> justification of keeping a dangling HEAD in a bare repository is.
>
> After all, the primary intended purpose of a bare repository is to serve
> as a distribution point (i.e. something you can clone from), and I think a
> dangling HEAD interferes with the usual operation of clone (although I've
> never tested this).
>
> Care to explain why?
I am taking a course with six programming projects. I want a separate
working tree for each project, but I want all the working trees
connected to the same repository because I often copy changes from one
project to another and that makes it more convenient to inspect the
history of one project while I am working on another. I didn't want to
put the repository inside an arbitrary one of the working trees, so I
left it bare, and I didn't want to point its HEAD to an arbitrary one of
the projects, so I left it unborn.
The upshot is that I am using a bare repository as a distribution point
for *working trees* (via git-new-workdir), not for push/pull.
Matt
^ permalink raw reply
* Re: Is rebase always destructive?
From: Andreas Ericsson @ 2008-12-01 16:45 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngj7jch.2srb.csaba-ml@beastie.creo.hu>
Csaba Henk wrote:
> Hi,
>
> When doing a rebase, I can find a number of reasons for which one might
> feel like to preserve the rebased branch (that is, perform an operation
> which copies the branch over a new base, not moves).
>
> - For example, a successful rebase doesn't necessarily mean that the
> code, as of the rebased branch, is consistent and compiles. That is,
> the rebase can be broken even if git can put things together diff-wise.
> In such a case I wouldn't be happy to lose the original instance of
> the branch.
>
> - Or I might want to build different versions of the program, and each
> version of it needs a given set of fixes (the same one). Then rebasing
> my bugfix branch is not a good idea, I'd much rather copy it over all
> those versions.
>
> I can't see any option for rebase which would yield this cp-like
> behaviour. Am I missing something? Or people don't need such a feature?
> (Then give me some LART please, my mind is not yet gittified enough to
> see why is this not needed.) Or is it usually done by other means, not
> rebase?
>
When I feel I'm in any danger of ending up with mis-compiles or whatnot,
I usually do
git checkout -b try-rebase
git rebase $target
which does exactly what you want.
For almost all other operations, it's possible to get your previous
branch-pointer back, either by referencing ORIG_HEAD, or the reflogs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: SPEC files for Git
From: Todd Zullinger @ 2008-12-01 16:42 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: git
In-Reply-To: <4933FFC6.8080306@morey-chaisemartin.com>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Nicolas Morey-Chaisemartin wrote:
> I'm trying to recompile gitweb1.6.0.4-1 for RHEL5, but I'm missing
> the spec file. I've checked the git SRP. It generates a lot of
> things but no RPM for gitweb.
>
> Is there any place with an official spec file? Or has anyone made
> one which he could share?
Far from official, but here's what I've been using, based on the
Fedora and EPEL packages: http://tmz.fedorapeople.org/tmp/git/el5/
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Many people are secretly interested in life.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Add backslash to list of 'crud' characters in real name
From: Linus Torvalds @ 2008-12-01 16:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
We remove crud characters at the beginning and end of real-names so that
when we see email addresses like
From: "David S. Miller" <davem@davemloft.net>
we drop the quotes around the name when we parse that and split it up into
name and email.
However, the list of crud characters was basically just a random list of
common things that are found around names, and it didn't contain the
backslash character that some insane scripts seem to use when quoting
things. So now the kernel has a number of authors listed like
Author: \"Rafael J. Wysocki\ <rjw@sisk.pl>
because the author name had started out as
From: \"Rafael J. Wysocki\" <rjw@sisk.pl>
and the only "crud" character we noticed and removed was the final
double-quote at the end.
We should probably do better quote removal from names anyway, but this is
the minimal obvious patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
ident.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ident.c b/ident.c
index 09cf0c9..99f1c85 100644
--- a/ident.c
+++ b/ident.c
@@ -121,6 +121,7 @@ static int crud(unsigned char c)
c == '<' ||
c == '>' ||
c == '"' ||
+ c == '\\' ||
c == '\'';
}
^ permalink raw reply related
* Re: gitk: git bisect view doesn't work
From: Johannes Sixt @ 2008-12-01 16:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <4933F819.1010701@viscovery.net>
Johannes Sixt schrieb:
> gitk bails out like this if I do "git bisect view":
>
> $ git bisect start HEAD HEAD~2
> Bisecting: 0 revisions left to test after this
> [9a61060c7e0d112d0742f5b845210ea8c41b6c6b] Added encoding
>
> $ git bisect view
> Error in startup script: can't read "notflag": no such variable
> while executing
> "expr {!$notflag}"
> ("--not" arm line 2)
> invoked from within
> "switch -glob -- $arg {
> "-d" -
> "--date-order" {
> set vdatemode($n) 1
> # remove from origargs in case we hit an unknown option
> set origarg..."
> (procedure "parseviewargs" line 21)
> invoked from within
> "parseviewargs $view $args"
> (procedure "start_rev_list" line 27)
> invoked from within
> "start_rev_list $curview"
> (procedure "getcommits" line 5)
> invoked from within
> "getcommits {}"
> (file "/usr/local/bin/gitk" line 10897)
Bisection points to this commit:
commit 2958228430b63f2e38c55519d1f98d8d6d9e23f3
Author: Paul Mackerras <paulus@samba.org>
Date: Tue Nov 18 19:44:20 2008 +1100
gitk: Fix switch statement in parseviewargs
-- Hannes
^ permalink raw reply
* [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-12-01 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson, j.sixt
In-Reply-To: <4933A058.3050101@viscovery.net>
From: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
* I notice a handful platforms do not define THREADED_DELTA_SEARCH, and
on them Linus's preload-index.c is the first source file that includes
<pthreads.h>, which may result in breakages.
Made the default for AIX <5 and Mingw
Author should still show as Junio, apologies if not
Makefile | 17 ++++++++++++++++-
config.mak.in | 1 +
configure.ac | 5 +++++
preload-index.c | 9 +++++++++
4 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index d1e2116..5a69a41 100644
--- a/Makefile
+++ b/Makefile
@@ -90,6 +90,8 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
+#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).
#
@@ -164,6 +166,7 @@ uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
+uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
# CFLAGS and LDFLAGS are for the users to override from the command line.
@@ -722,6 +725,11 @@ ifeq ($(uname_S),AIX)
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
+ ifneq ($(shell expr "$(uname_V)" : '[1234]'),1)
+ THREADED_DELTA_SEARCH = YesPlease
+ else
+ NO_PTHREADS = YesPlease
+ endif
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
@@ -766,6 +774,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
+ NO_PTHREADS = YesPlease
NEEDS_LIBICONV = YesPlease
OLD_ICONV = YesPlease
NO_C99_FORMAT = YesPlease
@@ -1017,9 +1026,15 @@ ifdef INTERNAL_QSORT
COMPAT_OBJS += compat/qsort.o
endif
+ifdef NO_PTHREADS
+ THREADED_DELTA_SEARCH =
+ BASIC_CFLAGS += -DNO_PTHREADS
+else
+ EXTLIBS += $(PTHREAD_LIBS)
+endif
+
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
- EXTLIBS += $(PTHREAD_LIBS)
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
diff --git a/config.mak.in b/config.mak.in
index ea7705c..14dfb21 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -51,4 +51,5 @@ OLD_ICONV=@OLD_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
FREAD_READS_DIRECTORIES=@FREAD_READS_DIRECTORIES@
SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
+NO_PTHREADS=@NO_PTHREADS@
PTHREAD_LIBS=@PTHREAD_LIBS@
diff --git a/configure.ac b/configure.ac
index 4256742..8821b50 100644
--- a/configure.ac
+++ b/configure.ac
@@ -490,6 +490,8 @@ AC_SUBST(NO_MKDTEMP)
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
+# Define NO_PTHREADS if we do not have pthreads
+#
# Define PTHREAD_LIBS to the linker flag used for Pthread support.
AC_LANG_CONFTEST([AC_LANG_PROGRAM(
[[#include <pthread.h>]],
@@ -502,9 +504,12 @@ else
${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
if test $? -eq 0;then
PTHREAD_LIBS="-lpthread"
+ else
+ NO_PTHREADS=UnfortunatelyYes
fi
fi
AC_SUBST(PTHREAD_LIBS)
+AC_SUBST(NO_PTHREADS)
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
diff --git a/preload-index.c b/preload-index.c
index a685583..88edc5f 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -2,6 +2,14 @@
* Copyright (C) 2008 Linus Torvalds
*/
#include "cache.h"
+
+#ifdef NO_PTHREADS
+static void preload_index(struct index_state *index, const char **pathspec)
+{
+ ; /* nothing */
+}
+#else
+
#include <pthread.h>
/*
@@ -81,6 +89,7 @@ static void preload_index(struct index_state *index, const char **pathspec)
die("unable to join threaded lstat");
}
}
+#endif
int read_index_preload(struct index_state *index, const char **pathspec)
{
--
1.6.0.2.229.g1293c.dirty
^ permalink raw reply related
* [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-12-01 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson, j.sixt
In-Reply-To: <4933A058.3050101@viscovery.net>
From: Junio C Hamano <gitster@pobox.com>
This introduces make variable NO_PTHREADS for platforms that lack the
support for pthreads library or people who do not want to use it for
whatever reason. When defined, it makes the multi-threaded index
preloading into a no-op, and also disables threaded delta searching by
pack-objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
* I notice a handful platforms do not define THREADED_DELTA_SEARCH, and
on them Linus's preload-index.c is the first source file that includes
<pthreads.h>, which may result in breakages.
Made the default for AIX <5 and Mingw
With correct commit message. Sorry for the previous attempt.
Makefile | 17 ++++++++++++++++-
config.mak.in | 1 +
configure.ac | 5 +++++
preload-index.c | 9 +++++++++
4 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index d1e2116..5a69a41 100644
--- a/Makefile
+++ b/Makefile
@@ -90,6 +90,8 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
+#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).
#
@@ -164,6 +166,7 @@ uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
+uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
# CFLAGS and LDFLAGS are for the users to override from the command line.
@@ -722,6 +725,11 @@ ifeq ($(uname_S),AIX)
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
+ ifneq ($(shell expr "$(uname_V)" : '[1234]'),1)
+ THREADED_DELTA_SEARCH = YesPlease
+ else
+ NO_PTHREADS = YesPlease
+ endif
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
@@ -766,6 +774,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
+ NO_PTHREADS = YesPlease
NEEDS_LIBICONV = YesPlease
OLD_ICONV = YesPlease
NO_C99_FORMAT = YesPlease
@@ -1017,9 +1026,15 @@ ifdef INTERNAL_QSORT
COMPAT_OBJS += compat/qsort.o
endif
+ifdef NO_PTHREADS
+ THREADED_DELTA_SEARCH =
+ BASIC_CFLAGS += -DNO_PTHREADS
+else
+ EXTLIBS += $(PTHREAD_LIBS)
+endif
+
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
- EXTLIBS += $(PTHREAD_LIBS)
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
diff --git a/config.mak.in b/config.mak.in
index ea7705c..14dfb21 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -51,4 +51,5 @@ OLD_ICONV=@OLD_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
FREAD_READS_DIRECTORIES=@FREAD_READS_DIRECTORIES@
SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
+NO_PTHREADS=@NO_PTHREADS@
PTHREAD_LIBS=@PTHREAD_LIBS@
diff --git a/configure.ac b/configure.ac
index 4256742..8821b50 100644
--- a/configure.ac
+++ b/configure.ac
@@ -490,6 +490,8 @@ AC_SUBST(NO_MKDTEMP)
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
+# Define NO_PTHREADS if we do not have pthreads
+#
# Define PTHREAD_LIBS to the linker flag used for Pthread support.
AC_LANG_CONFTEST([AC_LANG_PROGRAM(
[[#include <pthread.h>]],
@@ -502,9 +504,12 @@ else
${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
if test $? -eq 0;then
PTHREAD_LIBS="-lpthread"
+ else
+ NO_PTHREADS=UnfortunatelyYes
fi
fi
AC_SUBST(PTHREAD_LIBS)
+AC_SUBST(NO_PTHREADS)
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
diff --git a/preload-index.c b/preload-index.c
index a685583..88edc5f 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -2,6 +2,14 @@
* Copyright (C) 2008 Linus Torvalds
*/
#include "cache.h"
+
+#ifdef NO_PTHREADS
+static void preload_index(struct index_state *index, const char **pathspec)
+{
+ ; /* nothing */
+}
+#else
+
#include <pthread.h>
/*
@@ -81,6 +89,7 @@ static void preload_index(struct index_state *index, const char **pathspec)
die("unable to join threaded lstat");
}
}
+#endif
int read_index_preload(struct index_state *index, const char **pathspec)
{
--
1.6.0.2.229.g1293c.dirty
^ permalink raw reply related
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Shawn O. Pearce @ 2008-12-01 16:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228140775-29212-6-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> This implements the server side of protocol extension to show which branch
> the HEAD points at. The information is sent after the terminating NUL
> that comes after the server capabilities list, to cause older clients to
> ignore it, while allowing newer clients to make use of that information
Ok, not to paint the bikeshed another color or anything ... but
can we do something to make this slightly more extensible? I like
the "lets hide it behind the NUL" bit a lot better than the prior
iteration, but I wonder if we shouldn't do something slightly
different.
Maybe we put on the first capability line a flag that lets the
client know we have symref data in the advertised list, and then
instead of sticking only HEAD into that first ref we put the names
of the symrefs after the ref they point to.
So we might see something like:
xxxx......................... refs/heads/boo\0with-symref\0
xxxx......................... refs/heads/master\0HEAD\0
xxxx......................... refs/remotes/origin/HEAD\0refs/remotes/origin/master\0
etc. Its probably harder to produce the output for, but it permits
advertising all of the symrefs on the remote side, which may be good
for --mirror, among other uses. It also should make it easier to put
multiple symrefs down pointing at the same real ref, they could just
be a space delimited list stored after the ref name, and if its the
first ref in the stream, after the other capability advertisement.
Actually, since the capability line is space delimited and space is
not valid in a ref name, we could just include into the capability
line like "symref=HEAD", but I still like the idea of listing it
after each ref, to reduce the risk of running into pkt-line length
limitations.
--
Shawn.
^ permalink raw reply
* Re: SPEC files for Git
From: Michael J Gruber @ 2008-12-01 16:00 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <4933FFC6.8080306@morey-chaisemartin.com>
Nicolas Morey-Chaisemartin venit, vidit, dixit 01.12.2008 16:16:
> Hi,
>
> I'm trying to recompile gitweb1.6.0.4-1 for RHEL5, but I'm missing the
> spec file.
> I've checked the git SRP. It generates a lot of things but no RPM for
> gitweb.
RHEL5 probably comes with git 1.5.something, and its spec file won't
work nicely with git 1.6.x (because of new install locations).
> Is there any place with an official spec file? Or has anyone made one
> which he could share?
git source comes with a spec file template. If you have a git checkout
(or source tree) then "make git.spec" will generate it.
It does not generate a gitweb subpackage, but you only need to add a few
lines, following the example of the archimport package, say.
Or, even simpler: Just take the srpm from Fedora 10 and rebuild (gitweb
is a subpackage of git in F10, so you need the git srpm (e.g.
'yumdownloader --source gitweb' on an F10 instance). Installing the srpm
(as non-root) gives you the spec, I'm sure you know ;)
Michael
^ permalink raw reply
* Re: RPM for gitweb (was: SPEC files for git)
From: Jakub Narebski @ 2008-12-01 15:57 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: git
In-Reply-To: <4933FFC6.8080306@morey-chaisemartin.com>
Nicolas Morey-Chaisemartin <devel@morey-chaisemartin.com> writes:
> I'm trying to recompile gitweb-1.6.0.4-1 for RHEL5, but I'm missing
> the spec file. I've checked the git SRPM.
Which SRPM? The one for RHEL or Fedora Core, or the one from
http://www.kernel.org/pub/software/scm/git/RPMS/SRPMS/ ?
> It generates a lot of things but no RPM for gitweb.
>
> Is there any place with an official spec file? Or has anyone made one
> which he could share?
The .spec file for various git subpackages (git, git-all, git-svn,
gitk, git-gui, git-email, perl-Git, etc.) is in git src.rpm file, and
source for it can be found as git.spec.in file in git.git repository.
There is no gitweb RPM subpackage in generic .spec file from git.git
repository (from kernel.org) because 1.) installation of CGI scripts
(or mod_perl legacy scripts) depends on distribution (what web server
is installed, where and how config for this web server is managed);
2.) there is no standard place where to put git repositories to be
hosted by gitweb like /var/www/html/ or /var/www/cgi-bin/
Read gitweb/INSTALL[1] from git repository on how to install gitweb.
[1] http://repo.or.cz/w/git.git/:/gitweb/README
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/6 (v2)] Detecting HEAD more reliably while cloning
From: Johannes Sixt @ 2008-12-01 15:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228140775-29212-1-git-send-email-gitster@pobox.com>
Junio C Hamano schrieb:
> Instead of introducing a full-fledged protocol extension, this round hides
> the new information in the same place as the server capabilities list that
> is used to implement protocol extension is hidden from older clients.
Not that it makes a lot of difference, but why do you want to *hide* the
information? Can't we just have a capability-with-parameter:
... shallow no-progress include-tag head=refs/heads/foo\ bar ...
(with spaces and backslashes escaped)?
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jakub Narebski @ 2008-12-01 15:40 UTC (permalink / raw)
To: git
In-Reply-To: <1228140775-29212-6-git-send-email-gitster@pobox.com>
Junio C Hamano wrote:
> This implements the server side of protocol extension to show which branch
> the HEAD points at. The information is sent after the terminating NUL
> that comes after the server capabilities list, to cause older clients to
> ignore it, while allowing newer clients to make use of that information
By the way, is negotiating protocol extensions, and supported protocol
extensions documented somewhere in Documentation/technical/ ?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: two questions about the format of loose object
From: Shawn O. Pearce @ 2008-12-01 15:32 UTC (permalink / raw)
To: Liu Yubao; +Cc: git list
In-Reply-To: <493399B7.5000505@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
>
> In current implementation the loose objects are compressed:
>
> loose object = deflate(typename + <space> + size + '\0' + data)
...
> * Question 1:
>
> Why not use the format below for loose object?
> loose object = typename + <space> + size + '\0' + deflate(data)
Historical accident. We really should have used a format more
like what you are asking here, because it makes inflation easier.
The pack file format uses a header structure sort of like this,
for exactly that reason. IOW we did learn our mistakes and fix them.
If you look up the new style loose object code you'll see that it
has a format like this (sort of), the header is actually the same
format that is used in the pack files, making it smaller than what
you propose but also easier to unpack as the code can be reused
with the pack reading code.
Unfortunately the new style loose object was phased out; it never
really took off and it made the code much more complex. So it was
pulled in commit 726f852b0ed7e03e88c419a9996c3815911c9db1:
Author: Nicolas Pitre <nico@cam.org>:
> deprecate the new loose object header format
>
> Now that we encourage and actively preserve objects in a packed form
> more agressively than we did at the time the new loose object format and
> core.legacyheaders were introduced, that extra loose object format
> doesn't appear to be worth it anymore.
>
> Because the packing of loose objects has to go through the delta match
> loop anyway, and since most of them should end up being deltified in
> most cases, there is really little advantage to have this parallel loose
> object format as the CPU savings it might provide is rather lost in the
> noise in the end.
>
> This patch gets rid of core.legacyheaders, preserve the legacy format as
> the only writable loose object format and deprecate the other one to
> keep things simpler.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/8] generate-cmdlist.sh: avoid selecting synopsis at wrong place
From: Johannes Schindelin @ 2008-12-01 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vtz9oq92i.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 1 Dec 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > As it is, the patch series is _already_ hard to review (as it is large
> > not only in term of number of patches, but also individual patch
> > size), _especially_ given the fact that there is no clear, precise and
> > short description of why/how the sparse checkout is implemented.
>
> Hmm, can you really tell the lack of such description without reading
> the series, I have to wonder...
Okay, I thought it was obvious, but here is a template for the BLURP of
the cover letter that would at least get me started:
-- snip --
A "sparse checkout" is an index/working directory pair where not all
files/directories of the HEAD commit are actually checked out in the
working directory. Instead, they are marked as "not being checked out" in
the index.
The real meat of this series is patch *** M/N *** which teaches Git to
understand the *** XYZ flag *** for index entries.
The following operations are affected by sparse checkout: *** X, Y, Z ***
These operations respect sparse checkouts by *** THIS, THIS AND THIS ***.
The first patch really should be independent, but patch *** M/N *** would
fail without it.
-- snap --
And of course, the whole BLURP should not consist of 10-20 line
paragraphs, but try to fit everything into 3-4 line paragraphs (I seem to
remember that there was a mail on this list saying than more than 4
lines/paragraph are too much for the average attention span...).
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox