* Recent issues
From: Junio C Hamano @ 2007-07-07 7:31 UTC (permalink / raw)
To: git; +Cc: jnareb, pasky, ltuikov, paulus
Here is a list of recent issues on the list that I am aware of,
but not much have been done on.
To use the Message-ID, you can use:
http://mid.gmane.org/$message_id
where $message_id is the Message-ID without surrounding <>.
* gitweb patches (bunch of them)
From: Matt McCutchen <hashproduct@gmail.com>
Subject: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
Message-ID: <1183053733.6108.0.camel@mattlaptop2>
From: Matt McCutchen <hashproduct@gmail.com>
Subject: [PATCH] gitweb: make search form generate pathinfo-style URLs
Message-ID: <1183057027.6108.4.camel@mattlaptop2>
From: Matt McCutchen <hashproduct@gmail.com>
Subject: [PATCH] gitweb: make "No commits" in project list gray, not bold green
Message-ID: <1183068922.6108.8.camel@mattlaptop2>
From: Miklos Vajna <vmiklos@frugalware.org>
Subject: [PATCH] gitweb: prefer git_get_project_owner() over get_file_owner()
Message-ID: <20070703221122.GI32766@genesis.frugalware.org>
From: Michael Hendricks <michael@ndrix.org>
Subject: [PATCH] gitweb: configurable width for the projects list Description column
Message-ID: <11835958082458-git-send-email-michael@ndrix.org>
Haven't heard any from gitweb folks about these; I'd take a look
at them if I find time this weekend.
* gitk --left-right
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
From: Junio C Hamano <junkio@cox.net>
Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>
Paulus?
* gitk tree view fix
From: Brian Downing <bdowning@lavos.net>
Subject: [PATCH] gitk: Fix for tree view ending in nested directories
Message-ID: <20070704212643.GR4087@lavos.net>
Paulus?
* switching branches when b changes between symlink and directory in a/b/c
From: Pierre Habouzit <madcoder@debian.org>
Subject: [BUG (or misfeature?)] git checkout and symlinks
Message-ID: <20070704203541.GA13286@artemis.corp>
Will take a look.
* cherry-pick unexpected conflicts
From: Gerrit Pape <pape@smarden.org>
Subject: Re: unexpected git-cherry-pick conflict
Message-ID: <20070613134336.13661.qmail@c61f4fed932273.315fe32.mid.smarden.org>
* git-apply -R --whitespace=warn
From: Daniel Barkalow <barkalow@iabervon.org>
Message-ID: <Pine.LNX.4.64.0707062155170.6977@iabervon.org>
Subject: Minor bug in git-apply's patch-cleaning
* Use gitattributes for more things.
- Customized "diff -p" markers per path.
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] Per-path attribute based hunk header selection.
Message-ID: <alpine.LFD.0.98.0707061051020.9434@woody.linux-foundation.org>
Will take a look and try to finish this before 1.5.3-rc1.
^ permalink raw reply
* Re: [PATCH] Use /etc/mailname for the hostname part of the email address.
From: Junio C Hamano @ 2007-07-07 6:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matt Kraai, git, Matt Kraai
In-Reply-To: <alpine.LFD.0.999.0707061945220.31544@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The thing is, I actually personally tend to _prefer_ the committer name as
> being "user@hostname" rather than a "real" email address.
>
> It often tells you something much more.
I remember you said exactly the same thing before. But I wonder
if "committer" e-mail address is really the place you would want
to use as (one of) the source of reliable information for that
kind of thing. The information obviously can be used among
people who exchange commits via git-pull, but what about people
whose changes are always fed as e-mailed patches?
For such people, if they would want to encode the auxiliary
information in their author name like you do with g5 and woody,
would you recommend they put the in-body From: header, which may
not be working e-mail addresses to reach them?
^ permalink raw reply
* Re: [PATCH] Enable "git rerere" by the config variable rerere.enabled
From: Junio C Hamano @ 2007-07-07 5:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0707061303450.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Earlier, "git rerere" was enabled by creating the directory
> .git/rr-cache. That is definitely not in line with most other
> features, which are enabled by a config variable.
>
> So, check the config variable "rerere.enabled". If it is set
> to "false" explicitely, do not activate rerere, even if
> .git/rr-cache exists. This should help when you want to disable
> rerere temporarily.
>
> If "rerere.enabled" is not set at all, fall back to detection
> of the directory .git/rr-cache.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Touches quite some parts, doesn't it?
>
> And yeah, the git-gui part should be factored out, I guess. Shawn?
I'll exclude git-gui part and commit with a minor tweaks; having
extra "does the directory exist" check in git-gui would not hurt
people who are used to how rerere works in the short term, and I
think I read somewhere that I should expect git-gui updates over
the weekend anyway.
> -int cmd_rerere(int argc, const char **argv, const char *prefix)
> +int is_rerere_enabled(void)
> {
This will be "static".
> - struct path_list merge_rr = { NULL, 0, 0, 1 };
> - int i, fd = -1;
> struct stat st;
> + const char *rr_cache = git_path("rr-cache");
> + int rr_cache_exists;
>
> - if (stat(git_path("rr-cache"), &st) || !S_ISDIR(st.st_mode))
> + if (!rerere_enabled)
> return 0;
As git_path() is not zero-cost, assignment to rr_cache will be
moved here.
>
> + rr_cache_exists = !stat(rr_cache, &st) && S_ISDIR(st.st_mode);
> + if (rerere_enabled < 0)
> + return rr_cache_exists;
> +
> + if (!rr_cache_exists && (mkdir(rr_cache, 0777) ||
> + adjust_shared_perm(rr_cache)))
> + die("Could not create directory %s", rr_cache);
> + return 1;
> +}
If rr-cache is a regular file, we will hit "Could not create
directory" which is exactly what we want anyway. Even if it is
a dangling symlink, it would fail with "File exists", so that
should be Ok.
^ permalink raw reply
* Re: [PATCH] Disallow empty GIT_AUTHOR_NAME or GIT_COMMITTER_NAME
From: Junio C Hamano @ 2007-07-07 5:45 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <468E80D3.5060706@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Attempt normal methods for determining user name if
> GIT_AUTHOR_NAME or GIT_COMMITTER_NAME is set to the empty
> string. Then fall back to using the user login name.
>
> Previously, if these environment variables were set to the
> empty string, a message would be printed complaining about
> missing gecos information. In this case the gecos information
> was never checked.
>
> This still allows an empty GIT_AUTHOR_EMAIL or GIT_COMMITTER_EMAIL.
> Possibly someone would want to use these variables to disable
> the respective email address string?
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Thanks. But this makes me wonder why you do not do the same
check for !*email
> Then I send the patch to myself using git-format-patch and then
> git-send-email. These two format the patch appropriately for
> submission and allow me to set the message-id.
>
> Then I select the message, right-click and choose "Edit As New...",
> edit, select the recipients, and send. I also now have a record of
> the sent message which I would not have if I used only git-send-email.
I would just add myself to --bcc when running send-email; much
simpler ;-).
> ident.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ident.c b/ident.c
> index 3d49608..6932ccf 100644
> --- a/ident.c
> +++ b/ident.c
> @@ -193,7 +193,7 @@ const char *fmt_ident(const char *name, const char *email,
> int i;
>
> setup_ident();
> - if (!name)
> + if (!name || !*name)
> name = git_default_name;
> if (!email)
> email = git_default_email;
> --
> 1.5.3.rc0.30.g114f-dirty
^ permalink raw reply
* Re: [PATCH] Use /etc/mailname for the hostname part of the email address.
From: Linus Torvalds @ 2007-07-07 2:54 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Matt Kraai
In-Reply-To: <11837748652889-git-send-email-kraai@ftbfs.org>
On Fri, 6 Jul 2007, Matt Kraai wrote:
>
> From: Matt Kraai <kraai@asturias.ftbfs.org>
>
> /etc/mailname contains the hostname to be used on outgoing email
> messages generated locally on Debian systems
I think this is taking us into a bad direction.
The thing is, I actually personally tend to _prefer_ the committer name as
being "user@hostname" rather than a "real" email address.
It often tells you something much more.
For example, take a look at the kernel archive, and do
git log --author=torvalds
and notice how the exact author string changes - not just because
"osdl.org" became "linux-foundation.org", but because it ends up encoding
which *machine* I did things on.
For example, while I do almost all my work at any time on my "main"
machine (right now "woody" - not because I'm horny, but because it's an
Intel woodcrest machine, the way my previous main machine was called "g5"
because it was an IBM PowerPC G5 machine), but I sometimes do things on
another machine because that's the machine that showed the problem, or was
the machine that it got tested on (32-bit x86 things: "macmini" or "evo"),
or it was just the laptop I use while travelling ("evo" again).
IOW, I don't think the authorship really even _has_ to be seen as a "real
email" address. The "user@hostname" in many ways is nicer. Sure, when the
patches come in as emails (which ends up being most of them), it obviously
ends up being the email, but I don't think that's at all required.
If you actually want to contact the people involved with a patch, you
should use the "Signed-off-by:" and "Cc:" lines in the commit message, not
necessarily the author thing!
Linus
^ permalink raw reply
* Minor bug in git-apply's patch-cleaning
From: Daniel Barkalow @ 2007-07-07 2:21 UTC (permalink / raw)
To: git
If you apply in reverse a patch which adds junk (e.g., terminal
whitespace), it complains about the junk you're adding, even though (since
it's in reverse) you're actually removing that junk.
It's arguable as to whether it should complain about junk in - lines with
--reverse; it's likely that you care more about getting the patch
unapplied exactly than not reintroducing removed whitespace. But
complaining about junk in + lines is actually confusing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Use /etc/mailname for the hostname part of the email address.
From: Matt Kraai @ 2007-07-07 2:21 UTC (permalink / raw)
To: git; +Cc: Matt Kraai, Matt Kraai
From: Matt Kraai <kraai@asturias.ftbfs.org>
/etc/mailname contains the hostname to be used on outgoing email
messages generated locally on Debian systems (cf.
http://www.debian.org/doc/debian-policy/ch-customized-programs.html).
If it available, use it instead of gethostname or gethostbyname.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
If this is only appropriate for the Debian package, I
apologize. Please let me know if this is the case and I'll
submit it to the Debian maintainer.
ident.c | 26 +++++++++++++++++++++++++-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/ident.c b/ident.c
index 6612d17..3d05ae2 100644
--- a/ident.c
+++ b/ident.c
@@ -43,6 +43,27 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
}
+static int getmailname(char *name, size_t len)
+{
+ FILE *f = fopen("/etc/mailname", "r");
+ int i;
+
+ if (!f)
+ return -1;
+ if (!fgets(name, len, f)) {
+ fclose(f);
+ return -1;
+ }
+ fclose(f);
+ for (i = 0; !isspace(name[i]); i++)
+ ;
+ if (name[i - 1] != '.')
+ name[i] = '\0';
+ else
+ name[i - 1] = '\0';
+ return 0;
+}
+
static void copy_email(const struct passwd *pw)
{
/*
@@ -54,7 +75,10 @@ static void copy_email(const struct passwd *pw)
die("Your sysadmin must hate you!");
memcpy(git_default_email, pw->pw_name, len);
git_default_email[len++] = '@';
- gethostname(git_default_email + len, sizeof(git_default_email) - len);
+ if (getmailname(git_default_email + len,
+ sizeof(git_default_email) - len) < 0)
+ gethostname(git_default_email + len,
+ sizeof(git_default_email) - len);
if (!strchr(git_default_email+len, '.')) {
struct hostent *he = gethostbyname(git_default_email + len);
char *domainname;
--
1.5.2.3
^ permalink raw reply related
* Re: [RFC/PATCH] interpolate '\n' as newline
From: Junio C Hamano @ 2007-07-07 2:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707062100360.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> All places which call interpolate() get this interpolation for free.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> In the back of my head, I remembered that a few people
> were interested in this.
>
> Judging by the diffstat, it really escapes me why these people
> did not implement it.
>
> However, there is a chance that this change is not liked by
> all places that call interpolate(). merge-recursive can live
> with it, I guess.
I actually think merge-recursive has much bigger chance of
getting broken than git-daemon, but only _if_ people are already
using custom merge programs this becomes an issue. It is much
more common to see two letter sequence '\n' as a string literal
in a script than in a pathname.
> But daemon interpolates the path... However,
> it seems only the command line of daemon can change the string,
> so this change should be safe.
The command line needs to say --interpolated-path="...\n..."
and expect that '\n' would come out as two characters backslash
and en in the _pathname_ to get broken, and it is very unlikely
that anybody is insane enough to have such a path.
^ permalink raw reply
* Re: [PATCH] Per-path attribute based hunk header selection.
From: Junio C Hamano @ 2007-07-07 2:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.98.0707061051020.9434@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> In .gitattributes:
>
> *.java diff=java
> *.perl diff=perl
> *.doc diff=doc
>
> In .git/config
>
> [diff "java"]
> command = internal
> funcname = ... # ugly and complicated regexp to override the built-in one.
>
> [diff "perl"]
> command = internal
> funcname = ...
>
> [diff "doc"]
> command = ms-doc-diff
>
> Doesn't this make more sense and mesh much better with the already
> existing custom diff driver?
>
> (And yeah, maybe we could instead of "command=internal" just have the rule
> that "internal" is the default, and you'd not have a command at all when
> you want to run the internal diff.
>
> Just an idea. I don't have any code.
Yeah, I'd be lying if I said that this did not cross my mind
when I saw existing diff.*.command handling.
About the comment from Johannes regarding hunk_header vs
funcname, I would actually prefer hunk_header, since that is
what this is about ("funcname" and "find_func" were misnomer
from the beginning), but I'd rename hunk_header to funcname for
the sake of consistency and minimizing the diff.
Will find time to look at this over the weekend.
^ permalink raw reply
* Re: [PATCH] Add [verse] to the SYNOPSIS section of git-submodule.txt.
From: Junio C Hamano @ 2007-07-07 1:56 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <11837697912125-git-send-email-kraai@ftbfs.org>
Thanks!
^ permalink raw reply
* [PATCH] Change "added.moved or removed" to "added, moved or removed" in
From: Matt Kraai @ 2007-07-07 1:23 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Documentation/core-intro.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt
index eea44d9..f3cc223 100644
--- a/Documentation/core-intro.txt
+++ b/Documentation/core-intro.txt
@@ -528,7 +528,7 @@ paths that have been trivially merged.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
--
1.5.2.3
^ permalink raw reply related
* Re: git-gc "--aggressive" somewhat broken
From: Linus Torvalds @ 2007-07-07 1:16 UTC (permalink / raw)
To: Theodore Tso, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707061512550.8278@woody.linux-foundation.org>
On Fri, 6 Jul 2007, Linus Torvalds wrote:
>
> This is a totally untested patch that may or may not work.
And by that I obviously mean "does not work".
I only tested on the gcc thing, and it causes an assertion error when
trying to actually write out the deltas ("corrupt packed object").
I'm sure somebody can figure it out,
Linus
^ permalink raw reply
* [PATCH] Add [verse] to the SYNOPSIS section of git-submodule.txt.
From: Matt Kraai @ 2007-07-07 0:56 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
The SYNOPSIS section of git-submodule.txt contains two forms. Since
it doesn't use the verse style, the line boundary between them is not
preserved and the second form can appear on the same line as the first
form. Adding [verse] enables the verse style, which preserves the
line boundary between them.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Documentation/git-submodule.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7f0904e..d76ae47 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -8,6 +8,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
+[verse]
'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
--
1.5.2.3
^ permalink raw reply related
* git-svn set-tree
From: Tjernlund @ 2007-07-07 0:03 UTC (permalink / raw)
To: git
I have noticed that if I do a git-svn set-tree, remotes/git-svn retains the parent
from the branch where set-tree was performed.
If a coworker wants recreate my tree by using git-svn init && git-svn fetch
he looses the parent I have in my tree.
I wonder if not git-svn set-tree can record the parent information in the
svn repos log, so that git-svn init/fetch can recreate the parent relationship?
Jocke
^ permalink raw reply
* Re: git-gc "--aggressive" somewhat broken
From: Linus Torvalds @ 2007-07-06 22:17 UTC (permalink / raw)
To: Theodore Tso, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707061310390.8278@woody.linux-foundation.org>
On Fri, 6 Jul 2007, Linus Torvalds wrote:
>
> If we want to be really aggressive, we migth decide to pass a new flag to
> pack-objects that does something closer to what "aggressive" was meant to
> do: it would use existing delta's if they exist, but _despite_ existing it
> could look if there are even better choices.
This is a totally untested patch that may or may not work.
The reason I say "may not work" is not just that I haven't really tested
it, it's also because I haven't thought it through very well.
In particular, does this possibly cause infinite loops of delta chains?
Probably. It would need code to explicitly make sure that we don't do
that, but I couldn't even convince myself as to why we might not hit that
case _already_ with delta re-use, so maybe there's something going that
protects us against it.
The patch itself is trivial, except for hunk #2, which fixes up the fact
that we didn't fill in the "entry->size" correctly for a delta entry (we
left it at the *delta* size). It didn't use to matter, since the entry
size wasn't ever used for anything, I think (with the possible exception
of the object sorting).
Anyway, consider this a starting point for somebody else who wants to
really try to look into this. But I do think that "git gc --aggressive" is
broken as it stands now.
Linus
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3d396ca..89e9900 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -57,6 +57,7 @@ static struct object_entry *objects;
static struct object_entry **written_list;
static uint32_t nr_objects, nr_alloc, nr_result, nr_written;
+static int aggressive;
static int non_empty;
static int no_reuse_delta, no_reuse_object;
static int local;
@@ -1179,6 +1180,8 @@ static void check_object(struct object_entry *entry)
entry->delta = base_entry;
entry->delta_sibling = base_entry->delta_child;
base_entry->delta_child = entry;
+ entry->size = get_size_from_delta(p, &w_curs,
+ entry->in_pack_offset + entry->in_pack_header_size);
unuse_pack(&w_curs);
return;
}
@@ -1425,7 +1428,7 @@ static void find_deltas(struct object_entry **list, int window, int depth)
if (progress)
display_progress(&progress_state, processed);
- if (entry->delta)
+ if (entry->delta && !aggressive)
/* This happens if we decided to reuse existing
* delta from a pack. "!no_reuse_delta &&" is implied.
*/
@@ -1760,6 +1763,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
die("bad %s", arg);
continue;
}
+ if (!strcmp("--aggressive", arg)) {
+ aggressive = 1;
+ continue;
+ }
usage(pack_usage);
}
^ permalink raw reply related
* Re: [StGIT RFC] Changing patch@branch syntaxtackable> ::= <nameattr> | <stackable>:<stackable>
From: Yann Dirson @ 2007-07-06 22:04 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <20070626223143.GG7730@nan92-1-81-57-214-146.fbx.proxad.net>
My thoughts about stg-show suggested me we can extend on the latest
proposed syntax, by allowing comma-separated sequences of patch
ranges. Such ranges would not be limitted to patches either, they
would be meaningful within any patchset (or maybe within ordered
patchsets only, should we feel this restriction necessary). Eg:
stg show <pool>:<stack>:foo,bar..buz
Patch attributes OTOH probably don't play well with ranges - which I
take as a symptom that we should be careful about them.
We may also want to generalize the patch//attribute mechanism a bit
more, eg. so "base" is not seen as a fake patch, but rather an
attribute of the patchset. That is, something like
"<pool>:<stack>//base" should be a valid id.
Let's try to get a full formal syntax, based on the one you formerly
proposed.
<name> ::= [^\w.-]+
<attr> ::= 'top' | 'top.old' | 'bottom' | 'bottom.old' | 'log' | ...
<patchname>|<stackname>|<poolname>|<hydraname> ::= <name>
<patchsetname> ::= <stackname> | <poolname> | <hydraname>
<patchset> ::= <patchsetname> ? | <patchset> ':' <patchsetname> ?
<patch> := <patchset> ':' <patchname>
<commitid> ::= ( <patch> | <patchset> ) ? '//' <attr>
<simplerange0> ::= <name> | <name> '..' <name>? | '..' <name>
<simplerange> ::= <simplerange> | <simplerange0> ',' <simplerange>
<range> := <patchset> ':' <simplerange>
On Wed, Jun 27, 2007 at 12:31:43AM +0200, Yann Dirson wrote:
> On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote:
> > Can a patch series be part of multiple pools? This would be useful to
> > my workflow.
>
> In the current prototype, yes, since the current "hydra" object only
> binds existing stacks. In the design we've discussed, not directly -
> let's find a solution.
>
> My idea of what we've discussed most recently is that stackables will
> be *contained* in patchsets. Ie. a pool will be able to contain both
> patches-as-we-know-them, and stacks, but those stacks won't be git
> heads, only refs in a namespace still to be decided upon - something
> similar to how we currently store patch refs.
>
> To allow sharing a stack between several pools, I can see 2 options.
> The easiest to implement (but not necessarily the easiest to live
> with) is to clone and sync the stack.
Given the complexity of the approaches I proposed, we may want to keep
an "hydra" type besides "pools". After all, we may implement as many
PatchSet subclasses we can think of :)
Best regards,
--
Yann
^ permalink raw reply
* [RFC/PATCH] git-branch: default to --track
From: Johannes Schindelin @ 2007-07-06 21:54 UTC (permalink / raw)
To: git, gitster
"git branch --track" will setup config variables when branching from
a remote branch, so that if you say "git pull" while being on that
branch, it automatically fetches the correct remote, and merges the
correct branch.
Often people complain that this is not the default for "git branch".
Make it so.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
With 1.5.3 knocking at the door, maybe it is too late to include
this. However, I am in favour of changing the default behaviour
here.
builtin-branch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index ae450b0..507b47c 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -22,7 +22,7 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
-static int branch_track_remotes;
+static int branch_track_remotes = 1;
static int branch_use_color;
static char branch_colors[][COLOR_MAXLEN] = {
^ permalink raw reply related
* Re: [PATCH] Deprecate git-cherry
From: Johannes Schindelin @ 2007-07-06 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyy9dzrr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 6 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > A cleaner alternative was introduced in v1.5.2~185^2~1, which not only
> > allows you to list the commits, but to inspect them, too:
> >
> > git log --cherry-pick <upstream>...[<head>]
> >
> > There is a functional difference, though: git cherry shows both
> > directions, <upstream>...<head> and <head>...<upstream>, and prefixes
> > the commits with '+' and '-', respectively.
> >
> > 'git rev-list --cherry-pick <upstream>...[<head>]' only shows one
> > direction, and does not prefix the commits.
>
> Eh, --left-right anybody?
>
> git-cherry is used by people's scripts, and I do not think
> deprecating is an option at least in the short term.
Okay, I should have been more precise.
Maybe there are some interesting scripts that use "git cherry". I'd like
to see them (which does not mean that I vote for git-cherry removal).
Personally, I use "git rev-list --cherry-pick", because it spares me one
call to sed.
However, I do not think that there is much value in advertising it any
more. There is much more value in "git log --cherry-pick", since you can
get the commit messages and the patches by just adding one more flag (and
absent any path parameter, that can be even _at the end_ of the command
line, making it even more convenient).
So what I meat was: advertise "git log --cherry-pick" instead of "git
cherry", since it is vastly more useful.
There is one real consequence on my common usage, though: It annoys me
whenever I want to cherry pick a commit, which happens quite often, that
the bash completion completes on this (for me) useless command. I would
like to see that gone (but only after a grace period, evidently).
Ciao,
Dscho
^ permalink raw reply
* qgit: added "Renames following" in annotation
From: Marco Costalba @ 2007-07-06 20:53 UTC (permalink / raw)
To: Git Mailing List
I've just pushed (git://git.kernel.org/pub/scm/qgit/qgit4.git) a patch
series that add "renames following" to file annotation in qgit
preserving the non-linear (graph) history.
The most interesting cases in git tree are:
builtin-fsck.c (multiple renames)
builtin-mailinfo.c (multiple renames and changed directory)
git-clone.sh (nice history graph)
but the coolest is by far builtin-tar-tree.c where the file has been
renamed from tar- tree.c to builtin-tar-tree.c in _two_ different
commits on _two_ different branches then merged togheter in commit
1af0d11283...
To handle the latest one, a cool generalization has been necessary.
I have tested with _all_ the git files, and it seems to work in all the cases.
Have fun
Marco
^ permalink raw reply
* Re: [PATCH] Deprecate git-cherry
From: Junio C Hamano @ 2007-07-06 20:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707061722020.4093@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> A cleaner alternative was introduced in v1.5.2~185^2~1, which not only
> allows you to list the commits, but to inspect them, too:
>
> git log --cherry-pick <upstream>...[<head>]
>
> There is a functional difference, though: git cherry shows both
> directions, <upstream>...<head> and <head>...<upstream>, and prefixes
> the commits with '+' and '-', respectively.
>
> 'git rev-list --cherry-pick <upstream>...[<head>]' only shows one
> direction, and does not prefix the commits.
Eh, --left-right anybody?
git-cherry is used by people's scripts, and I do not think
deprecating is an option at least in the short term.
^ permalink raw reply
* git-gc "--aggressive" somewhat broken
From: Linus Torvalds @ 2007-07-06 20:19 UTC (permalink / raw)
To: Theodore Tso, Junio C Hamano; +Cc: Git Mailing List
This flag seems misdesigned as-is.
It makes the window bigger (good, and aggressive), but it also enabled
"-f".
Which sometimes causes _worse_ packing.
In particular, there's a gcc import at
git://git.infradead.org/toolchain/gcc.git
which apparently packs down quite nicely to a 450MB pack, but when it gets
repacked "aggressively", it blows up to 1.4GB. The reason? That pack was
generated using --depth=100 --window=100 (I think).
So under certain circumstances, "--aggressive" is anything _but_
aggressive, and actually causes much worse packing.
If we want to be really aggressive, we migth decide to pass a new flag to
pack-objects that does something closer to what "aggressive" was meant to
do: it would use existing delta's if they exist, but _despite_ existing it
could look if there are even better choices.
So right now we have:
- default behaviour:
always re-use existing deltas, don't look at alternatives at all.
This is optimal for CPU/memory/IO usage, and is generally a good idea
- "-f" (and as a result, the current bad "git gc --aggressive"):
never re-use existing deltas, always look for new ones.
This is good if you have reason to believe that the old choices are
bad, or you need to force re-generation of deltas (because you want to
force a new pack-file format, for example)
and the missing piece might be
- "git pack-objects --aggressive":
re-use existing deltas _and_ look for even better ones.
This is good if all you're looking for is better packing.
Hmm?
Linus
^ permalink raw reply
* [RFC/PATCH] interpolate '\n' as newline
From: Johannes Schindelin @ 2007-07-06 20:02 UTC (permalink / raw)
To: git, gitster
All places which call interpolate() get this interpolation for free.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
In the back of my head, I remembered that a few people
were interested in this.
Judging by the diffstat, it really escapes me why these people
did not implement it.
However, there is a chance that this change is not liked by
all places that call interpolate(). merge-recursive can live
with it, I guess. But daemon interpolates the path... However,
it seems only the command line of daemon can change the string,
so this change should be safe. There is only one other place in
git.git, the --pretty=format: stuff, and that is where the idea
was born first.
interpolate.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/interpolate.c b/interpolate.c
index 0082677..b322503 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -87,6 +87,12 @@ unsigned long interpolate(char *result, unsigned long reslen,
src += namelen;
continue;
}
+ } else if (c == '\\' && src[1] == 'n') {
+ if (newlen + 1 < reslen)
+ *dest++ = '\n';
+ src += 2;
+ newlen++;
+ continue;
}
/* Straight copy one non-interpolation character. */
if (newlen + 1 < reslen)
^ permalink raw reply related
* Re: Update local tracking refs when pushing- no way to disable
From: Johannes Schindelin @ 2007-07-06 19:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707061514090.6977@iabervon.org>
Hi,
On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> On Fri, 6 Jul 2007, Johannes Schindelin wrote:
>
> > On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> >
> > > On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> > >
> > > > Related, but not identical, is the problem illustrated in
> > > > http://thread.gmane.org/gmane.comp.version-control.git/49888
> > > >
> > > > IMHO there is a bug. IIUC git push first looks for common ref
> > > > names on the local and remote side (yes, refs/remotes are excluded
> > > > since v1.5.3-rc0~9, but the underlying problem is still there).
> > > > Then it pushes them. But here, something seems to have gone wrong:
> > > > refs/remotes/origin/HEAD is a symref. And the corresponding ref is
> > > > updated. Should git-push not just _not_ update symrefs?
> > >
> > > I believe this actually have nothing to do with git-push; it's
> > > actually git-receive-pack and maybe git-send-pack. Probably
> > > git-receive-pack shouldn't list symrefs at all, or should somehow
> > > report them as links so that they can be compared as links. The only
> > > refs that git-push itself updates are tracking refs on the local
> > > side for refs on the remote side which were updated. In the report,
> > > the reporter had (obviously) not configured any local tracking refs
> > > for the remote's tracking refs.
> >
> > Sorry, I think I did not make myself clear. The updates refs were
> > _local_ refs. And they _were_ symrefs.
>
> No, no local refs were updated. This would have given the message "Also
> local refs/remotes/origin/HEAD", which wasn't there. What was updated
> was tracking refs on the remote (which were created as local tracking
> refs when somebody was running git commands local to the repository
> which, for the failing command, was remote). The logic for updating
> local refs on a push was not used at all in this case, according to the
> output in the message you linked to.
Okay, I misunderstood, then.
Sorry for the noise,
Dscho
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Daniel Barkalow @ 2007-07-06 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707061958540.4093@racer.site>
On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 6 Jul 2007, Daniel Barkalow wrote:
>
> > On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> >
> > > Related, but not identical, is the problem illustrated in
> > > http://thread.gmane.org/gmane.comp.version-control.git/49888
> > >
> > > IMHO there is a bug. IIUC git push first looks for common ref names on
> > > the local and remote side (yes, refs/remotes are excluded since
> > > v1.5.3-rc0~9, but the underlying problem is still there). Then it
> > > pushes them. But here, something seems to have gone wrong:
> > > refs/remotes/origin/HEAD is a symref. And the corresponding ref is
> > > updated. Should git-push not just _not_ update symrefs?
> >
> > I believe this actually have nothing to do with git-push; it's actually
> > git-receive-pack and maybe git-send-pack. Probably git-receive-pack
> > shouldn't list symrefs at all, or should somehow report them as links so
> > that they can be compared as links. The only refs that git-push itself
> > updates are tracking refs on the local side for refs on the remote side
> > which were updated. In the report, the reporter had (obviously) not
> > configured any local tracking refs for the remote's tracking refs.
>
> Sorry, I think I did not make myself clear. The updates refs were _local_
> refs. And they _were_ symrefs.
No, no local refs were updated. This would have given the message "Also
local refs/remotes/origin/HEAD", which wasn't there. What was updated was
tracking refs on the remote (which were created as local tracking refs
when somebody was running git commands local to the repository which, for
the failing command, was remote). The logic for updating local refs on a
push was not used at all in this case, according to the output in the
message you linked to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Johannes Schindelin @ 2007-07-06 18:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707061440050.14638@iabervon.org>
Hi,
On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> On Fri, 6 Jul 2007, Johannes Schindelin wrote:
>
> > Related, but not identical, is the problem illustrated in
> > http://thread.gmane.org/gmane.comp.version-control.git/49888
> >
> > IMHO there is a bug. IIUC git push first looks for common ref names on
> > the local and remote side (yes, refs/remotes are excluded since
> > v1.5.3-rc0~9, but the underlying problem is still there). Then it
> > pushes them. But here, something seems to have gone wrong:
> > refs/remotes/origin/HEAD is a symref. And the corresponding ref is
> > updated. Should git-push not just _not_ update symrefs?
>
> I believe this actually have nothing to do with git-push; it's actually
> git-receive-pack and maybe git-send-pack. Probably git-receive-pack
> shouldn't list symrefs at all, or should somehow report them as links so
> that they can be compared as links. The only refs that git-push itself
> updates are tracking refs on the local side for refs on the remote side
> which were updated. In the report, the reporter had (obviously) not
> configured any local tracking refs for the remote's tracking refs.
Sorry, I think I did not make myself clear. The updates refs were _local_
refs. And they _were_ symrefs.
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