* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 20:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <alpine.DEB.1.00.0811102030180.30769@pacific.mpi-cbg.de>
Le Monday 10 November 2008 20:46:02 Johannes Schindelin, vous avez écrit :
> Hi,
>
> On Mon, 10 Nov 2008, Francis Galiegue wrote:
> > A very nice git feature, without even going as far as merges, is the
> > cherry pick feature.
> >
> > For this to be doable from within the Eclipse Git plugin, a diff/patch
> > implementation needs to be found, in a license compatible with the
> > current JGit license (3-clause BSD, as far as I can tell). Or a new
> > implementation can be rewritten from scratch, of course.
>
> Do not forget creating efficient packs. They also need an efficient diff
> engine.
>
I wasn't even thinking about this, honestly :p
Let's say that as far as IDE users are concerned, they do have disk space, and
having the ability to cherry-pick is more of a priority than packs ;) Even a
less efficient but "to the point" engine will be good enough for the time
being, or at least, this is what I think.
I understand way too little about the algorithm myself to tell whether it's
also efficient for such a purpose. Maybe it is...
--
fge
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-10 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de>
2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Sun, 9 Nov 2008, Alex Riesen wrote:
>>
>> Oh, I am. But it is just so convenient to have range support for
>> commands which just show commits. Besides, git-show just errors out,
>> instead of producing the commits like git-log does.
>
> Have fun implementing the support, and then explaining to users why this
> shows only one commit:
>
> git show HEAD^..HEAD HEAD~10
>
for cs in HEAD^..HEAD HEAD~10; do
case "$cs"; in
*..*)
git format-patch --stdout "$cs"
;;
*)
git show --pretty=email "$cs"
;;
esac
done
At least, this is what I have in mind and how I expect it to work.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Francis Galiegue @ 2008-11-10 20:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michal Nazarewicz, git
In-Reply-To: <200811102117.30372.jnareb@gmail.com>
Le Monday 10 November 2008 21:17:29 Jakub Narebski, vous avez écrit :
> Michal Nazarewicz wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >> Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:
> >>> Jakub Narebski <jnareb@gmail.com> writes:
> >>>> The reason why git doesn't support keywords like $Revision$ or $Date$
> >>>> is performance: the $Revision$ and $Date$ are keywords related to
> >>>> _commit_ data, not blob data.
> >>>
> >>> In my case identifying content not commit would be even better.
> >>
> >> Well, in that case using `ident` attribute would be enough
> >> (but cryptic).
> >
> > Yes, but it forces me to do some voodoo magic (ie. checkout) to get the
> > Id in the file, ;) like so:
> >
> > #v+
> > $ echo '$Id$'>bar && git add bar && git commit -m 'Added bar' && cat bar
> > Created commit d49d436: Added bar
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> > create mode 100644 bar
> > $Id$
> > $ rm bar && git checkout bar && cat bar
> > $Id: 055c8729cdcc372500a08db659c045e16c4409fb $
> > #v-
>
> Well, _some_ command has to be invoked to expand keywords. "git add"
> doesn't do that (perhaps it should?), so you need to use checkout.
>
If "git add" aims to do that, you'd have to be very, VERY careful, not to
substitute in the wrong place to start with, not to attempt substitution in
binary files...
And this would have a sizeable cost, imho. If you really want to do this,
isn't there a hook somewhere that can do that for you, instead of modifying
git add directly?
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Thomas Harning @ 2008-11-10 20:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0811102049460.30769@pacific.mpi-cbg.de>
On Nov 10, 2008, at 2:51 PM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 10 Nov 2008, Jeff King wrote:
>
>> On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote:
>>
>>> Just wondering, has there been any looking into whether the git-
>>> notes
>>> concept can track rebases?
>>
>> Not that I know of, but then again, I'm not sure exactly what you
>> mean
>> by "track rebases".
>
> I guess he means that you could have something like this
>
> rebased from <SHA-1>
>
> in the notes for any given commit, so that _if_ you have the commit,
> e.g.
> gitk could show that connection (maybe dashed in the graphical history
> display, and as a "Rebased from:" link).
What I intended is that if notes are attached to 'A', A` (after a
rebase) will have the exact same note.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 20:32 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Michal Nazarewicz, git
In-Reply-To: <200811102124.59973.fg@one2team.com>
Dnia poniedziałek 10. listopada 2008 21:24, Francis Galiegue napisał:
> Le Monday 10 November 2008 21:17:29 Jakub Narebski, vous avez écrit :
> > Well, _some_ command has to be invoked to expand keywords. "git add"
> > doesn't do that (perhaps it should?), so you need to use checkout.
> >
>
> If "git add" aims to do that, you'd have to be very, VERY careful, not to
> substitute in the wrong place to start with, not to attempt substitution in
> binary files...
>
> And this would have a sizeable cost, imho. If you really want to do this,
> isn't there a hook somewhere that can do that for you, instead of modifying
> git add directly?
If I remember correctly there was idea to add 'pre-add' or 'post-add'
hook...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Miklos Vajna @ 2008-11-10 20:34 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Jeff King, Johannes Schindelin, Thomas Harning
In-Reply-To: <200811102101.15285.johan@herland.net>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland <johan@herland.net> wrote:
> Does it make sense to teach "git rebase" the -x option from "git
> cherry-pick"? As with "git cherry-pick -x" it only makes sense to use it if
> your rebasing from a public branch.
But rebasing a public branch is always something we try to prevent. So
basically -x would be useful only in case the user does what we asked
not to do. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johannes Schindelin @ 2008-11-10 20:48 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Harning, git
In-Reply-To: <20081110195120.GA3688@sigill.intra.peff.net>
Hi,
On Mon, 10 Nov 2008, Jeff King wrote:
> On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote:
>
> > > Not that I know of, but then again, I'm not sure exactly what you
> > > mean by "track rebases".
> >
> > I guess he means that you could have something like this
> >
> > rebased from <SHA-1>
> >
> > in the notes for any given commit, so that _if_ you have the commit,
> > e.g. gitk could show that connection (maybe dashed in the graphical
> > history display, and as a "Rebased from:" link).
>
> You don't really need "notes" for that, though, since you can put that
> information into the commit message (or headers) if you choose. I guess
> it has the advantage of not polluting the commit for others.
Exactly. And it would have the nice side effect that you could use a
notes ref "rebases", and just not show it when you are not interested in
looking at rebases.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/4] remote: add a new 'origin' variable to the struct
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This allows one to track where was the remote's original source, so that
it's possible to decide if it makes sense to migrate it to the config
format or not.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
remote.c | 3 +++
remote.h | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index e530a21..cbb3e48 100644
--- a/remote.c
+++ b/remote.c
@@ -201,6 +201,7 @@ static void read_remotes_file(struct remote *remote)
if (!f)
return;
+ remote->origin = REMOTE_REMOTES;
while (fgets(buffer, BUF_SIZE, f)) {
int value_list;
char *s, *p;
@@ -261,6 +262,7 @@ static void read_branches_file(struct remote *remote)
s++;
if (!*s)
return;
+ remote->origin = REMOTE_BRANCHES;
p = s + strlen(s);
while (isspace(p[-1]))
*--p = 0;
@@ -350,6 +352,7 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!subkey)
return error("Config with no key for remote %s", name);
remote = make_remote(name, subkey - name);
+ remote->origin = REMOTE_CONFIG;
if (!strcmp(subkey, ".mirror"))
remote->mirror = git_config_bool(key, value);
else if (!strcmp(subkey, ".skipdefaultupdate"))
diff --git a/remote.h b/remote.h
index d2e170c..a46a5be 100644
--- a/remote.h
+++ b/remote.h
@@ -1,8 +1,15 @@
#ifndef REMOTE_H
#define REMOTE_H
+enum {
+ REMOTE_CONFIG,
+ REMOTE_REMOTES,
+ REMOTE_BRANCHES
+};
+
struct remote {
const char *name;
+ int origin;
const char **url;
int url_nr;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] git-remote: document the migration feature of the rename subcommand
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-remote.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 7b227b3..fad983e 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -66,6 +66,10 @@ was passed.
Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
++
+In case <old> and <new> are the same, and <old> is a file under
+`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+the configuration file format.
'rm'::
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] Implement git remote rename
From: Miklos Vajna @ 2008-11-10 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7v63nh1sc7.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 24, 2008 at 04:33:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> I suspect that if you record where you read the configuration from in
> "struct remote" and add necessary code to remove the original when
> rename.old is *not* coming from in-config definition, you would make
> it possible for repositories initialized with older git that has
> either $GIT_DIR/branches/origin or $GIT_DIR/remotes/origin to be
> migrated to the in-config format using "git remote rename origin
> origin".
Here are 4 patches to implement this + add the related
testcases/documentation.
Miklos Vajna (4):
remote: add a new 'origin' variable to the struct
git-remote rename: support remotes->config migration
git-remote rename: support branches->config migration
git-remote: document the migration feature of the rename subcommand
Documentation/git-remote.txt | 4 ++++
builtin-remote.c | 35 +++++++++++++++++++++++++++++++++++
remote.c | 3 +++
remote.h | 7 +++++++
t/t5505-remote.sh | 33 +++++++++++++++++++++++++++++++++
5 files changed, 82 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 3/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This is similar to the remotes->config one, but it makes the
branches->config conversion possible.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 2 ++
t/t5505-remote.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d9d0ba3..3af1876 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -384,6 +384,8 @@ static int migrate_file(struct remote *remote)
remote->fetch_refspec[i], buf.buf);
if (remote->origin == REMOTE_REMOTES)
path = git_path("remotes/%s", remote->name);
+ else if (remote->origin == REMOTE_BRANCHES)
+ path = git_path("branches/%s", remote->name);
if (path && unlink(path))
warning("failed to remove '%s'", path);
return 0;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 1567631..1f59960 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -364,4 +364,16 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
'
+test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' '
+ git clone one six &&
+ origin_url=$(pwd)/one &&
+ (cd six &&
+ git remote rm origin &&
+ echo "$origin_url" > .git/branches/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/branches/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] git-remote rename: support remotes->config migration
From: Miklos Vajna @ 2008-11-10 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226349595.git.vmiklos@frugalware.org>
This patch makes it possible to migrate a remote stored in a
$GIT_DIR/remotes/nick file to the configuration file format.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 33 +++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 21 +++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 1ca6cdb..d9d0ba3 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -359,6 +359,36 @@ static int read_remote_branches(const char *refname,
return 0;
}
+static int migrate_file(struct remote *remote)
+{
+ struct strbuf buf = STRBUF_INIT;
+ int i;
+ char *path = NULL;
+
+ strbuf_addf(&buf, "remote.%s.url", remote->name);
+ for (i = 0; i < remote->url_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->url[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->url[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.push", remote->name);
+ for (i = 0; i < remote->push_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->push_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->push_refspec[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", remote->name);
+ for (i = 0; i < remote->fetch_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->fetch_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->fetch_refspec[i], buf.buf);
+ if (remote->origin == REMOTE_REMOTES)
+ path = git_path("remotes/%s", remote->name);
+ if (path && unlink(path))
+ warning("failed to remove '%s'", path);
+ return 0;
+}
+
static int mv(int argc, const char **argv)
{
struct option options[] = {
@@ -381,6 +411,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
+ if (!strcmp(rename.old, rename.new) && oldremote->origin != REMOTE_CONFIG)
+ return migrate_file(oldremote);
+
newremote = remote_get(rename.new);
if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
die("remote %s already exists.", rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0c956ba..1567631 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -343,4 +343,25 @@ test_expect_success 'rename a remote' '
test "$(git config branch.master.remote)" = "upstream")
'
+
+cat > remotes_origin << EOF
+URL: $(pwd)/one
+Push: refs/heads/master:refs/heads/upstream
+Pull: refs/heads/master:refs/heads/origin
+EOF
+
+test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
+ git clone one five &&
+ origin_url=$(pwd)/one &&
+ (cd five &&
+ git remote rm origin &&
+ mkdir -p .git/remotes &&
+ cat ../remotes_origin > .git/remotes/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/remotes/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.push)" = "refs/heads/master:refs/heads/upstream" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Junio C Hamano @ 2008-11-10 20:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Linus Torvalds, Miles Bader, git
In-Reply-To: <alpine.DEB.1.00.0811102054470.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 9 Nov 2008, Alex Riesen wrote:
>
>> Oh, I am. But it is just so convenient to have range support for
>> commands which just show commits. Besides, git-show just errors out,
>> instead of producing the commits like git-log does.
>
> Have fun implementing the support, and then explaining to users why this
> shows only one commit:
>
> git show HEAD^..HEAD HEAD~10
I find what Alex says somewhat silly because show is always "no walk", and
range by definition means you need to walk.
But when you give that command line, Alex could also change the command to
show the HEAD and HEAD~10, by changing the way series of range parameters
are evaluated by the revision parsing machinery. You take HEAD^..HEAD and
come up with one set (that has only one commit, HEAD), you take the next
parameter HEAD~10 and come up with another set (that also has only one
commit, HEAD~10, because show does not walk), then you take union.
I personally do not want to see that happen, though. The way multiple
"ranges" that come from separate command line parameters combine using set
operator semantics is so useful to do something like...
git log ko/master..master ^maint
which is my way to ask "Which commits on master are the ones that I
haven't pushed out? By the way, I have pushed out maint already so I do
not want to see anything that is already in maint", where ko/master tracks
what I pushed out to the public repository at k.org; this query is used to
see if I can still rewrite commits when I find typo/thinko in them.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Junio C Hamano @ 2008-11-10 20:50 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <200811101522.13558.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> A very nice git feature, without even going as far as merges, is the cherry
> pick feature.
I thought cherry-picking needs to be done in terms of 3-way merge, not
diff piped to patch, for correctness's sake.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Shawn O. Pearce @ 2008-11-10 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Git Mailing List, Robin Rosenberg
In-Reply-To: <7v63mv5mro.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Francis Galiegue <fg@one2team.net> writes:
>
> > A very nice git feature, without even going as far as merges, is the cherry
> > pick feature.
>
> I thought cherry-picking needs to be done in terms of 3-way merge, not
> diff piped to patch, for correctness's sake.
Yea, the 3-way merge cherry-pick is better. But in a pinch you
can (usually) get correct results from a "diff | patch" pipeline.
Of course that doesn't always work, resulting in patches that don't
apply cleanly, or worse, that apply at the wrong place silently.
--
Shawn.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Brian Gernhardt @ 2008-11-10 20:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Francis Galiegue, Michal Nazarewicz, git
In-Reply-To: <200811102132.05472.jnareb@gmail.com>
On Nov 10, 2008, at 3:32 PM, Jakub Narebski wrote:
> Dnia poniedziałek 10. listopada 2008 21:24, Francis Galiegue
> napisał:
>> Le Monday 10 November 2008 21:17:29 Jakub Narebski, vous avez
>> écrit :
>
>>> Well, _some_ command has to be invoked to expand keywords. "git add"
>>> doesn't do that (perhaps it should?), so you need to use checkout.
>>>
>>
>> If "git add" aims to do that, you'd have to be very, VERY careful,
>> not to
>> substitute in the wrong place to start with, not to attempt
>> substitution in
>> binary files...
>>
>> And this would have a sizeable cost, imho. If you really want to do
>> this,
>> isn't there a hook somewhere that can do that for you, instead of
>> modifying
>> git add directly?
>
> If I remember correctly there was idea to add 'pre-add' or 'post-add'
> hook...
Without adding any additional hooks, you could use the post-commit
hook to look for any added/changed files containing $Id$ lines and
force a checkout of them.
Perhaps something as simple as the following in your .git/hooks/post-
commit (untested, caveat emptor, YMMV):
git diff --name-only --diff-filter=AM HEAD^ HEAD | \
while read file; do
rm "$file" && git checkout -- "$file"
end
~~ Brian
^ permalink raw reply
* Re: recognize loose local objects during repack
From: Junio C Hamano @ 2008-11-10 21:03 UTC (permalink / raw)
To: drafnel; +Cc: git, spearce, nico, ae
In-Reply-To: <2390436.1226296705080.JavaMail.teamon@b307.teamon.com>
drafnel@gmail.com writes:
> This was developed on top of the previous repack/pack-objects series.
Thanks. Looked alright from a cursory reading.
By the way, I've been meaning to suggest that we should straighten out the
semantics of "unpacked" vs "incremental".
What the latter means is quite clear. We are creating a new packfile to
bundle loose ones into one, and after the new packfile is installed we can
remove the loose objects.
But what --unpacked means often confuses people, primarily because it is a
performance heuristics that makes certain assumptions on how the objects
are packed.
Namely, "unpacked" is about discovery process of objects to be packed.
Without the option, we enumerate all objects that are reachable from the
commits in the given range, excluding the trees and blobs that should
exist in commits that are excluded (e.g, if you say "--objects A..B", we
exclude trees and blobs referenced by commit A).
With the option, we also omit commits that are packed. What's funny is
that their trees and blobs are omitted, even if they are loose ;-)
This is typically not an issue, because you do not say "pack only this
commit object, without its trees or blobs" when repacking, and because you
must have all the trees and blobs necessary for a commit available when
you pack a commit; for these reasons, the trees and blobs are typically
packed together with the commit. It is not an issue that the rev-list
with --unpacked option does not list loose trees and blobs that belong to
a packed commit for this reason.
You could however arrange so that a commit itself is packed but some of
the tree and blob objects it refers to are loose, in which case these
loose objects may not ever get repacked incrementally.
In an empty directory, try this:
git init &&
echo 0 >file && git add file && git commit -m initial &&
P=$(git rev-list HEAD | git pack-objects pack) &&
mv pack-$P.* .git/objects/pack/ &&
git prune && git count-objects -v
git repack && git count-objects -v
It packs only the commit object (and prunes it), leaving a tree and a blob
loose. The repack won't find anything to pack.
This is not so bad in the sense that it will never corrupt your
repository, but it is confusing. Admittedly, not peeking into a commit
that is packed is a reasonable good heuristics for performance reasons.
Interestingly enough, the object listing machinery do traverse into
parents of packed commits when --unpacked is given. So if you pack a
commit and arrange to keep its parents unpacked, they are subject to the
incremental repacking. In other words, the performance heuristics may not
be buying us very much --- we are traversing the history down to the root
commits regardless.
^ permalink raw reply
* [PATCH] Fixed non-literal format in printf-style calls
From: Daniel Lowe @ 2008-11-10 21:07 UTC (permalink / raw)
To: git; +Cc: Daniel Lowe
In-Reply-To: <3t9bmcAj9kThyafdZ9mPENosknipZInn9Qq9u9oVuN7X7qwiI4GqZg@cipher.nrlssc.navy.mil>
These were found using gcc 4.3.2-1ubuntu11 with the warning:
warning: format not a string literal and no format arguments
Incorporated suggestions from Brandon Casey <casey@nrlssc.navy.mil>.
---
builtin-check-attr.c | 2 +-
builtin-remote.c | 2 +-
bundle.c | 4 ++--
environment.c | 2 +-
fsck.c | 2 +-
grep.c | 6 +++---
hash-object.c | 2 +-
path.c | 4 ++--
refs.c | 2 +-
unpack-trees.c | 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index 4921341..15a04b7 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -97,7 +97,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
else if (stdin_paths && doubledash < argc)
errstr = "Can't specify files with --stdin";
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(check_attr_usage, check_attr_options);
}
diff --git a/builtin-remote.c b/builtin-remote.c
index e396a3a..47deb0a 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -320,7 +320,7 @@ static int add_branch_for_removal(const char *refname,
/* make sure that symrefs are deleted */
if (flags & REF_ISSYMREF)
- return unlink(git_path(refname));
+ return unlink(git_path("%s", refname));
item = string_list_append(refname, branches->branches);
item->util = xmalloc(20);
diff --git a/bundle.c b/bundle.c
index 7d17a1f..daecd8e 100644
--- a/bundle.c
+++ b/bundle.c
@@ -114,7 +114,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
continue;
}
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(e->sha1), e->name);
}
if (revs.pending.nr != p->nr)
@@ -139,7 +139,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
for (i = 0; i < req_nr; i++)
if (!(refs.objects[i].item->flags & SHOWN)) {
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(refs.objects[i].item->sha1),
refs.objects[i].name);
}
diff --git a/environment.c b/environment.c
index bf93a59..bb96ac0 100644
--- a/environment.c
+++ b/environment.c
@@ -118,7 +118,7 @@ const char *get_git_work_tree(void)
work_tree = git_work_tree_cfg;
/* make_absolute_path also normalizes the path */
if (work_tree && !is_absolute_path(work_tree))
- work_tree = xstrdup(make_absolute_path(git_path(work_tree)));
+ work_tree = xstrdup(make_absolute_path(git_path("%s", work_tree)));
} else if (work_tree)
work_tree = xstrdup(make_absolute_path(work_tree));
git_work_tree_initialized = 1;
diff --git a/fsck.c b/fsck.c
index 0cf5f01..97f76c5 100644
--- a/fsck.c
+++ b/fsck.c
@@ -326,7 +326,7 @@ int fsck_error_function(struct object *obj, int type, const char *fmt, ...)
die("this should not happen, your snprintf is broken");
}
- error(sb.buf);
+ error("%s", sb.buf);
strbuf_release(&sb);
return 1;
}
diff --git a/grep.c b/grep.c
index e2c190a..600f69f 100644
--- a/grep.c
+++ b/grep.c
@@ -514,7 +514,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
if (from <= last_shown)
from = last_shown + 1;
if (last_shown && from != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
while (from < lno) {
pcl = &prev[lno-from-1];
show_line(opt, pcl->bol, pcl->eol,
@@ -524,7 +524,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
last_shown = lno-1;
}
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
if (!opt->count)
show_line(opt, bol, eol, name, lno, ':');
last_shown = last_hit = lno;
@@ -535,7 +535,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* we need to show this line.
*/
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ fputs(hunk_mark, stdout);
show_line(opt, bol, eol, name, lno, '-');
last_shown = lno;
}
diff --git a/hash-object.c b/hash-object.c
index 20937ff..846e91a 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -110,7 +110,7 @@ int main(int argc, const char **argv)
}
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(hash_object_usage, hash_object_options);
}
diff --git a/path.c b/path.c
index eb24017..a074aea 100644
--- a/path.c
+++ b/path.c
@@ -41,7 +41,7 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
len = vsnprintf(buf, n, fmt, args);
va_end(args);
if (len >= n) {
- snprintf(buf, n, bad_path);
+ strlcpy(buf, bad_path, n);
return buf;
}
return cleanup_path(buf);
@@ -63,7 +63,7 @@ static char *git_vsnpath(char *buf, size_t n, const char *fmt, va_list args)
goto bad;
return cleanup_path(buf);
bad:
- snprintf(buf, n, bad_path);
+ strlcpy(buf, bad_path, n);
return buf;
}
diff --git a/refs.c b/refs.c
index 42bde72..33ced65 100644
--- a/refs.c
+++ b/refs.c
@@ -940,7 +940,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
lock->lk->filename[i] = 0;
path = lock->lk->filename;
} else {
- path = git_path(refname);
+ path = git_path("%s", refname);
}
err = unlink(path);
if (err && errno != ENOENT) {
diff --git a/unpack-trees.c b/unpack-trees.c
index e5749ef..54f301d 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -352,7 +352,7 @@ static int unpack_failed(struct unpack_trees_options *o, const char *message)
discard_index(&o->result);
if (!o->gently) {
if (message)
- return error(message);
+ return error("%s", message);
return -1;
}
return -1;
--
1.6.0.4
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-10 21:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <81b0412b0811101224gcffc958o6dbfcdc45e022874@mail.gmail.com>
Hi,
On Mon, 10 Nov 2008, Alex Riesen wrote:
> 2008/11/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > On Sun, 9 Nov 2008, Alex Riesen wrote:
> >>
> >> Oh, I am. But it is just so convenient to have range support for
> >> commands which just show commits. Besides, git-show just errors out,
> >> instead of producing the commits like git-log does.
> >
> > Have fun implementing the support, and then explaining to users why this
> > shows only one commit:
> >
> > git show HEAD^..HEAD HEAD~10
> >
>
> for cs in HEAD^..HEAD HEAD~10; do
> case "$cs"; in
> *..*)
> git format-patch --stdout "$cs"
> ;;
> *)
> git show --pretty=email "$cs"
> ;;
> esac
> done
>
> At least, this is what I have in mind and how I expect it to work.
That is not the way git-show is implemented (it uses setup_revisions() to
check for validity and to parse the arguments), and I cannot think of any
way to make this work without ugly workarounds.
Ciao,
Dscho
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-10 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Linus Torvalds, Miles Bader, git
In-Reply-To: <7vabc75n5q.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 10 Nov 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> Alex could also change the command to show the HEAD and HEAD~10, by
> changing the way series of range parameters are evaluated by the
> revision parsing machinery. You take HEAD^..HEAD and come up with one
> set (that has only one commit, HEAD), you take the next parameter
> HEAD~10 and come up with another set (that also has only one commit,
> HEAD~10, because show does not walk), then you take union.
>
> I personally do not want to see that happen, though. The way multiple
> "ranges" that come from separate command line parameters combine using set
> operator semantics is so useful to do something like...
>
> git log ko/master..master ^maint
>
> which is my way to ask "Which commits on master are the ones that I
> haven't pushed out?
Exactly one of my use cases, since we do not have ko/master,maint..master.
Ciao,
Dscho
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 21:31 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Git Mailing List, Robin Rosenberg,
Johannes Schindelin
In-Reply-To: <20081110205242.GH2932@spearce.org>
Le Monday 10 November 2008 21:52:42 Shawn O. Pearce, vous avez écrit :
> Junio C Hamano <gitster@pobox.com> wrote:
> > Francis Galiegue <fg@one2team.net> writes:
> > > A very nice git feature, without even going as far as merges, is the
> > > cherry pick feature.
> >
> > I thought cherry-picking needs to be done in terms of 3-way merge, not
> > diff piped to patch, for correctness's sake.
>
> Yea, the 3-way merge cherry-pick is better. But in a pinch you
> can (usually) get correct results from a "diff | patch" pipeline.
> Of course that doesn't always work, resulting in patches that don't
> apply cleanly, or worse, that apply at the wrong place silently.
Well, in this case, I'd say it's a case of a bottle being "half full" or "half
empty".
The availability of even a simple diff|patch in jgit, and its being available
in egit, would generally be seen as a "half full" bottle, and would, imho,
GREATLY increase the appeal factor of egit, all the more that you have plenty
of undo/redo ability in Eclipse... And, dare I say it, of git in general as
an SCM to be used in many environments where Eclipse is the de facto IDE.
I know, I may sound irritating, but...
--
fge
^ permalink raw reply
* overly smart rebase - bug or feature?
From: Fedor Sergeev @ 2008-11-10 21:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Roman.Shaposhnick
Folks,
I have recently hit a behavior which might well be a feature,
but it was very surprising (in a bad sense) to me.
I was trying to rebase a branch with changes in some file onto a branch
where this file was recently deleted. I would expect rebase to fail and
suggest me to resolve conflict manually.
However it somehow succeeded managing to find another file to patch instead
of the initial one:
] cat git-rebase-bug.sh
#!/bin/sh
git init
# create three files with the same contents
perl -e ' for ($i=0; $i < 10; $i++) { print "$i\n" } ' >Makefile
cp Makefile Makefile1
cp Makefile Makefile2
git add .
git commit -m"created 3 makefiles"
# delete one file
git rm Makefile
git commit -m"deleted 1 makefile"
# go to another branch, one step back
git checkout -b mod HEAD^
# modify contents of the file deleted in master branch
echo "#10" >>Makefile
git add -u
git commit -m"modified 1 makefile"
# now rebase "mod" on top of "master" not expecting it to succeed
git rebase master mod
]
] mkdir git-bug; cd git-bug
] ../git-rebase-bug.sh
....
First, rewinding head to replay your work on top of it...
Applying: modified 1 makefile
error: Makefile: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
]
Now if I look at the rebase result I see that it chose to patch "Makefile2"
instead of my lovely "Makefile" (why not Makefile1, btw ;) ):
] git log --stat -1 --pretty=oneline
ce0101fc7884bce3eb9724b75d654e7c40abf0fd modified 1 makefile
Makefile2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
]
I has always agreed with the claim that simple but reliable merge
(rebase, whatever) is much better than smartass one smarter than yourself.
And, to be honest, both merge and cherry-pick do not try to play smart:
] git reset --hard mod@{1}
] git checkout master
] git merge mod
CCONFLICT (delete/modify): Makefile deleted in HEAD and modified in mod. Version mod of Makefile left in tree.
Automatic merge failed; fix conflicts and then commit the result.
] git reset --hard
] git cherry-pick mod
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c f782a81' to retain authorship and message.
]
So, why rebase is smarter?
Yeah, and if it matters I tried it on 1.6.0.2 and 1.5.3.8 on Solaris and Linux.
best regards,
Fedor.
PS I had problems reaching this list, thus ccing Junio explicitly.
I'm not on the list, btw..
^ permalink raw reply
* [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-10 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Current git versions ignore everything after # (called <head> in the
following) when pushing. Older versions (before cf818348f1ab57),
interpret #<head> as part of the URL, which make git bail out.
Ignoring the <head> part for push (fetch respects them) is unlogical.
As branches origin from Cogito, it is the best to correct this by
using the behaviour of cg-push:
push HEAD to remote refs/heads/<head>
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
Documentation/urls-remotes.txt | 19 +++++++++++----
remote.c | 11 ++++++++
t/t5516-fetch-push.sh | 50 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 504ae8a..d9e284c 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -68,13 +68,22 @@ This file should have the following format:
------------
`<url>` is required; `#<head>` is optional.
-When you do not provide a refspec on the command line,
-git will use the following refspec, where `<head>` defaults to `master`,
-and `<repository>` is the name of this file
-you provided in the command line.
+
+Depending on the operation, git will use one of the following
+refsprecs, if you don't provide one on the command line.
+`<branch>` is the name of this file in `$GIT_DIR/branches` and
+`<head>` defaults to `master`.
+
+git fetch uses:
+
+------------
+ refs/heads/<head>:refs/heads/<branch>
+------------
+
+git push uses:
------------
- refs/heads/<head>:<repository>
+ HEAD:refs/heads/<head>
------------
diff --git a/remote.c b/remote.c
index e530a21..660b2ce 100644
--- a/remote.c
+++ b/remote.c
@@ -297,6 +297,17 @@ static void read_branches_file(struct remote *remote)
}
add_url_alias(remote, p);
add_fetch_refspec(remote, strbuf_detach(&branch, 0));
+ /*
+ * Cogito compatible push: push current HEAD to remote #branch
+ * (master if missing)
+ */
+ strbuf_init(&branch, 0);
+ strbuf_addstr(&branch, "HEAD");
+ if (frag)
+ strbuf_addf(&branch, ":refs/heads/%s", frag);
+ else
+ strbuf_addstr(&branch, ":refs/heads/master");
+ add_push_refspec(remote, strbuf_detach(&branch, 0));
remote->fetch_tags = 1; /* always auto-follow */
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index a6532cb..4426df9 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -523,4 +523,54 @@ test_expect_success 'allow push to HEAD of non-bare repository (config)' '
! grep "warning.*this may cause confusion" stderr
'
+test_expect_success 'fetch with branches' '
+ mk_empty &&
+ git branch second $the_first_commit &&
+ git checkout second &&
+ echo ".." > testrepo/.git/branches/branch1 &&
+ (cd testrepo &&
+ git fetch branch1 &&
+ r=$(git show-ref -s --verify refs/heads/branch1) &&
+ test "z$r" = "z$the_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'fetch with branches containing #' '
+ mk_empty &&
+ echo "..#second" > testrepo/.git/branches/branch2 &&
+ (cd testrepo &&
+ git fetch branch2 &&
+ r=$(git show-ref -s --verify refs/heads/branch2) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'push with branches' '
+ mk_empty &&
+ git checkout second &&
+ echo "testrepo" > .git/branches/branch1 &&
+ git push branch1 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/master) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ )
+'
+
+test_expect_success 'push with branches containing #' '
+ mk_empty &&
+ echo "testrepo#branch3" > .git/branches/branch2 &&
+ git push branch2 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/branch3) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johan Herland @ 2008-11-10 21:51 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Jeff King, Johannes Schindelin, Thomas Harning
In-Reply-To: <20081110203437.GW24201@genesis.frugalware.org>
On Monday 10 November 2008, Miklos Vajna wrote:
> On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland
<johan@herland.net> wrote:
> > Does it make sense to teach "git rebase" the -x option from "git
> > cherry-pick"? As with "git cherry-pick -x" it only makes sense to use
> > it if your rebasing from a public branch.
>
> But rebasing a public branch is always something we try to prevent. So
> basically -x would be useful only in case the user does what we asked
> not to do. ;-)
Sorry, I wasn't clear enough: I am talking about a copy-rebase, that is, the
original public branch is unchanged, but you copy patches from it by making
a local temporary branch that starts out in the same place and then
rebasing it onto the other public branch where your want the patches to end
up (followed by fast-forwarding the target branch and removing the temp
branch). This is basically identical to cherry-picking a range of commits,
but since "git cherry-pick" does not support cherry-picking a range of
commits, this is the only alternative, AFAICS.
However, it would probably be a better solution to make "git cherry-pick"
work on a commit range... (cf. the ongoing "multiple-commit cherry-pick"
thread)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-10 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20081110181023.GA22753@coredump.intra.peff.net>
On Mon, Nov 10, 2008 at 7:10 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 10, 2008 at 04:20:51PM +0100, Santi Béjar wrote:
>
>> Hi *,
>>
>> $subject since:
>>
>> 4f672ad (wt-status: load diff ui config, 2008-10-26)
>>
>> I tried to make a test case, but failed. I think because it is a bit
>> tricky the fake_editor/stdin/stdout stuff, so at the end I bisected it
>> by hand
>
> Sorry, I don't quite understand what the problem is. From reading your
> subject line, I expected that "git commit -v" would show the diff in
> your editor, but then accidentally also include it in the final commit
> message. But I can't seem to reproduce that.
>
> Can you describe the problem in more detail?
It is exactly as you described. I'll try in other systems.
Santi
^ 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