* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Jeff King @ 2008-11-10 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning, git
In-Reply-To: <alpine.DEB.1.00.0811102049460.30769@pacific.mpi-cbg.de>
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.
-Peff
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 20:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811101903.27685.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
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-
But never mind, since it seems hard to accomplish in git, I'll have to
learn to live without it. ;)
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johan Herland @ 2008-11-10 20:01 UTC (permalink / raw)
To: git; +Cc: Jeff King, Johannes Schindelin, Thomas Harning
In-Reply-To: <20081110195120.GA3688@sigill.intra.peff.net>
On Monday 10 November 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.
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.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 20:17 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <871vxjl5af.fsf@erwin.mina86.com>
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.
And checkout doesn't touch file if it is identical, so you need
to remove it first; nevertheless you don't need to use commit in
betwen, as "git checkout bar" would checkout file out of index (you
added contents of file to index with "git add bar").
--
Jakub Narebski
Poland
^ permalink raw reply
* 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
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