* Re: [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Linus Torvalds @ 2008-07-06 21:52 UTC (permalink / raw)
To: Don Zickus; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1215379261-10802-1-git-send-email-dzickus@redhat.com>
On Sun, 6 Jul 2008, Don Zickus wrote:
>
> I noticed this the other day, just never got a chance to send the fix out.
> This might be the same problem I ran into.
Ack. This patch does indeed seem to fix the test-case I had. Thanks,
Linus
^ permalink raw reply
* Re: [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Junio C Hamano @ 2008-07-06 22:13 UTC (permalink / raw)
To: Don Zickus; +Cc: git, torvalds
In-Reply-To: <1215379261-10802-1-git-send-email-dzickus@redhat.com>
Don Zickus <dzickus@redhat.com> writes:
> Boundary lines in emails are treated as a special case. As a result of
> processing the boundary line a new line will be read into the buffer.
>
> The string length variable 'len' is evaluated before the boundary case, thus
> there is the possibility the length of the string does not match the new
> line read in (in the boundary line case). This causes a partial output of
> the line to the patch file.
>
> The fix is trivial, evaluate the length of the string right before
> processing it.
Ah, I was about to bisect this to see where it needs to be fixed and if it
needs to be fixed in maint (or maint-1.5.5 and earlier). Thanks for doing
this before I got around to it.
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Junio C Hamano @ 2008-07-06 22:33 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <20080706203951.GB1721@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote:
>> Two other shorthands for naming a set that is formed by a commit
>> and its parent commits exists. `r1{caret}@` notation means all
>> parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
>> its all parents.
>
> So, I would say that rev^! is shorthand for rev^@..rev, but it does not
> actually work:
>
> git rev-list 7ac749c^@..7ac749c
> fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path
> not in the working tree.
>
> yet "^rev^@ rev" syntax does:
>
> git rev-list ^7ac749c^@ 7ac749c
> 7ac749c96d143ba4f76723959892cbaddbe8ed07
>
> Is it a bug or feature?
>
> Puzzled...
After reading these paragraphs from "SPECIFYING RANGES":
History traversing commands such as 'git-log' operate on a set
of commits, not just a single commit. To these commands,
specifying a single revision with the notation described in the
previous section means the set of commits reachable from that
commit, following the commit ancestry chain.
To exclude commits reachable from a commit, a prefix `{caret}`
notation is used. E.g. "`{caret}r1 r2`" means commits reachable
from `r2` but exclude the ones reachable from `r1`.
This set operation appears so often that there is a shorthand
for it. "`r1..r2`" is equivalent to "`{caret}r1 r2`". It is
the difference of two sets (subtract the set of commits
reachable from `r1` from the set of commits reachable from
`r2`).
it is obvious to me that the third paragraph talks about r1 that is a
single rev (refer to SPECIFYING REVISIONS section, which does _NOT_ talk
about rev^@ nor rev^!) and r2 that similarly is another single rev. So I
think it is fairly clear that your "r^@..r" example is nonsense.
But perhaps these paragraphs need to be further reworded to avoid the
confusion. I dunno.
^ permalink raw reply
* [JGIT PATCH 1/1] jgit: create a tag command
From: Robin Rosenberg @ 2008-07-06 22:41 UTC (permalink / raw)
To: 'Shawn O. Pearce'; +Cc: 'Marek Zawirski', git
This command allows us to create simple or annotated tags using the jgit command line.
PGP signed tags are not yet supported.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
I ned this for tagging self-jgit-managed automated builds of the Eclipse plugin.
I could do with an Ant task, but this will work too.
-- robin
org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java | 96 ++++++++++++++++++++
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
new file mode 100644
index 0000000..a9377f5
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com>
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.pgm;
+
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.PersonIdent;
+
+class Tag extends TextBuiltin {
+ @Override
+ void execute(String[] args) throws Exception {
+ String tagName = null;
+ String message = null;
+ boolean force = false;
+ for (int i = 0; i < args.length; ++i) {
+ if (args[i].equals("-f")) {
+ force = true;
+ continue;
+ }
+ if (args[i].equals("-m")) {
+ if (i < args.length - 2)
+ message = args[i++] + "\n";
+ else
+ usage();
+ continue;
+ }
+ if (args[i].startsWith("-m")) {
+ message = args[i].substring(2) + "\n";
+ continue;
+ }
+ if (args[i].startsWith("-") && i == args.length - 1)
+ usage();
+ if (i == args.length - 1) {
+ tagName = args[i];
+ continue;
+ }
+ usage();
+ }
+ if (!tagName.startsWith(Constants.TAGS_PREFIX + "/"))
+ tagName = Constants.TAGS_PREFIX + "/" + tagName;
+ if (!force && db.resolve(tagName) != null) {
+ throw die("fatal: tag '"
+ + tagName.substring(Constants.TAGS_PREFIX.length() + 1)
+ + "' exists");
+ }
+ org.spearce.jgit.lib.Tag tag = new org.spearce.jgit.lib.Tag(db);
+ tag.setObjId(db.resolve(Constants.HEAD));
+ if (message != null) {
+ message = message.replaceAll("\r", "");
+ tag.setMessage(message);
+ tag.setTagger(new PersonIdent(db));
+ tag.setType("commit");
+ }
+ tag.setTag(tagName.substring(Constants.TAGS_PREFIX.length() + 1));
+ tag.tag();
+ }
+
+ private void usage() {
+ new Throwable().printStackTrace();
+ throw die("Usage: -m message tag");
+ }
+}
--
1.5.6.2.220.g44701
^ permalink raw reply related
* Re: git-clone --quiet broken?
From: Alex Riesen @ 2008-07-06 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dave Jones, git, Daniel Barkalow
In-Reply-To: <7vmykvrfta.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Sun, Jul 06, 2008 02:56:17 +0200:
> Dave Jones <davej@codemonkey.org.uk> writes:
>
> > The server I run various git snapshots on recently got upgraded to git 1.5.6,
> > ...
> > I could run the clone with 2>/dev/null, but I'd really like to get
> > mail when something breaks instead of it being totally silent.
> >
> > I'm assuming this was an unintentional side-effect of some other recent change?
>
> Yeah, I would assume so, too ;-)
>
> Daniel, is this enough? From re-reading the scripted version of
> git-clone, it appears that we *might* need to squelch no-progress if the
> stdout is not tty; I do not offhand if you got that right when you
> rewrote this in C.
While at it, could we please have the first "Initialize" message
removed?
Initialize git/.git
Initialized empty Git repository in /home/davej/git-trees/git/.git/
The default output looks redundant (that of init_db too, but the full
path can be useful sometimes). Something like this, perhaps:
diff --git a/builtin-clone.c b/builtin-clone.c
index 643c7d4..4a0f1ab 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -421,7 +421,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
die("could not create leading directories of '%s'", git_dir);
set_git_dir(make_absolute_path(git_dir));
- fprintf(stderr, "Initialize %s\n", git_dir);
init_db(option_template, option_quiet ? INIT_DB_QUIET : 0);
/*
^ permalink raw reply related
* Re: "make test" works again (sort-of) on cygwin.
From: Alex Riesen @ 2008-07-06 23:11 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Junio C Hamano
In-Reply-To: <486FD4FB.6070803@ramsay1.demon.co.uk>
Ramsay Jones, Sat, Jul 05, 2008 22:09:31 +0200:
> Alex Riesen wrote:
> > Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:
> >
> >> Anyhow, the "sort-of" in the subject line, relates to the fact that
> >> I am seeing some test failures. In particular, all tests in
> >> t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
> >> tests involve chmod/permissions ...
> >
> > Don't run "make test" as root (or "backup operator" on windows).
> > OTOH, a windows machine is almost useless, unless you're a member of
> > local administrators group (which includes "backup" permission).
> >
>
> Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!
>
> Hmm, but is that really the reason for these failures? After all, (referring
> to the example you snipped) the permissions are respected for creating
> files in the directory, just not directories. Is the "root" user on
> windows only selectively omnipotent?
It is (it is the backup operators who can read open, even locked,
files), but it is boringly hard to find when and where. You can try
reading MSDN (or better don't, you'll live longer if you don't).
^ permalink raw reply
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Robin Rosenberg @ 2008-07-06 23:16 UTC (permalink / raw)
To: 'Shawn O. Pearce'; +Cc: 'Marek Zawirski', git
In-Reply-To: <200807070041.35873.robin.rosenberg.lists@dewire.com>
This command allows us to create simple or annotated tags.
PGP signed tags are not yet supported.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java | 102 ++++++++++++++++++++
1 files changed, 102 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
An obvious omission was not to allow the user to tag anything but HEAD.
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
new file mode 100644
index 0000000..110db6b
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com>
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.pgm;
+
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.PersonIdent;
+
+class Tag extends TextBuiltin {
+ @Override
+ void execute(String[] args) throws Exception {
+ String tagName = null;
+ String message = null;
+ String ref = "HEAD";
+ boolean force = false;
+ for (int i = 0; i < args.length; ++i) {
+ if (args[i].equals("-f")) {
+ force = true;
+ continue;
+ }
+ if (args[i].equals("-m")) {
+ if (i < args.length - 2)
+ message = args[i++] + "\n";
+ else
+ usage();
+ continue;
+ }
+ if (args[i].startsWith("-m")) {
+ message = args[i].substring(2) + "\n";
+ continue;
+ }
+ if (args[i].startsWith("-") && i == args.length - 1)
+ usage();
+ if (i == args.length - 2) {
+ tagName = args[i];
+ ref = args[i+1];
+ ++i;
+ continue;
+ }
+ if (i == args.length - 1) {
+ tagName = args[i];
+ continue;
+ }
+ usage();
+ }
+ if (!tagName.startsWith(Constants.TAGS_PREFIX + "/"))
+ tagName = Constants.TAGS_PREFIX + "/" + tagName;
+ if (!force && db.resolve(tagName) != null) {
+ throw die("fatal: tag '"
+ + tagName.substring(Constants.TAGS_PREFIX.length() + 1)
+ + "' exists");
+ }
+ org.spearce.jgit.lib.Tag tag = new org.spearce.jgit.lib.Tag(db);
+ tag.setObjId(db.resolve(ref));
+ if (message != null) {
+ message = message.replaceAll("\r", "");
+ tag.setMessage(message);
+ tag.setTagger(new PersonIdent(db));
+ tag.setType("commit");
+ }
+ tag.setTag(tagName.substring(Constants.TAGS_PREFIX.length() + 1));
+ tag.tag();
+ }
+
+ private void usage() {
+ throw die("Usage: -m message tag [head]");
+ }
+}
--
1.5.6.2.220.g44701
^ permalink raw reply related
* [JGIT PATCH 1/1] Fix local transport to invoke git-upload-pack during fetch
From: Shawn O. Pearce @ 2008-07-06 23:31 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
We need to use git-upload-pack, not git-receive-pack. This was
broken by accident in 57aa472a7ef5e9349c4c0aa1a3022a1e28499324.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/transport/TransportLocal.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
index b41d4af..155d59f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
@@ -125,7 +125,7 @@ class TransportLocal extends PackTransport {
LocalFetchConnection() throws TransportException {
super(TransportLocal.this);
- uploadPack = startProcessWithErrStream(getOptionReceivePack());
+ uploadPack = startProcessWithErrStream(getOptionUploadPack());
init(uploadPack.getInputStream(), uploadPack.getOutputStream());
readAdvertisedRefs();
}
--
1.5.6.74.g8a5e
^ permalink raw reply related
* git-svn sucks when it should not
From: Johannes Schindelin @ 2008-07-07 0:00 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi Eric,
I have the pleasure of needing to work with a subversion project where
parts of the webserver are password restricted.
In particular, I cannot access the parent directory, and one of
the branches is protected, too.
Maybe you remember me describing that problem on IRC a few weeks ago: yes,
it is still persistent.
Now, I thought that I know my way around Perl, at least a little bit, but
while git-svn barfed on the repository, I... uhm, well, you probably get
the idea.
The funny part is this: when I say "git svn clone $URL/trunk", or the same
with the absolute paths to the single tags, instead of "git svn clone -s
$URL", git-svn does the correct thing. It works, importing the stuff as
"git-svn".
So I tried to just edit out by hand the branches section, so that the
password-protected branch would not be a problem.
The result was surprising: git svn fetch exited with success, but it
did... absolutely nothing.
After a lot of frustrating hours, which were not at all helped by
brilliant variable names such as "r" and "gsv", I now know this: the log
contains paths that do not have a prefix "trunk", but "<dir>/trunk",
where "<dir>" is the last directory of the URL.
Changing git-svn's URL to the parent of <dir> is a no-go, since that is --
as I mentioned above -- password protected.
Yes, in a perfect world I could just force the admin to change that, but
no, this is not a perfect world, so do not even try to suggest that if
you want to help.
Changing the fetch line to "<dir>/trunk:refs/remotes/trunk" does not work
either, since git-svn cleverly checks $URL/<dir>/<dir>/trunk/.
I then tried to hack match_globs() and match_paths() to add that extra
prefix to the patterns, so that that extra prefix + trunk would be
matched and edited out. This happened to work out alright.
But I tried for several hours to get in a proper solution which does not
throw up on the tags, and I have to conclude that this piece of code is
not hackable by anybody else but you.
So I stand defeated by your program. Thank you.
My ugly, ugly workaround that is however easy, easy, is a shell script
that uses curl to find out what refs are new, and clones each ref
individually, then pushes all the results together into one repository.
Should not have been _that_ hard,
Dscho
^ permalink raw reply
* Re: [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Junio C Hamano @ 2008-07-07 0:09 UTC (permalink / raw)
To: Don Zickus; +Cc: git, torvalds
In-Reply-To: <1215379261-10802-1-git-send-email-dzickus@redhat.com>
> I noticed this the other day, just never got a chance to send the fix out.
> This might be the same problem I ran into.
>
> Cheers,
> Don
>
> builtin-mailinfo.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index 2894e34..cedda18 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -795,7 +795,7 @@ static void handle_body(void)
> int rc = 0;
> static char newline[2000];
> static char *np = newline;
> - int len = strlen(line);
> + int len;
>
> /* Skip up to the first boundary */
> if (content_top->boundary) {
> @@ -814,6 +814,9 @@ static void handle_body(void)
> return;
> }
>
> + /* line may have changed after handling boundary, check len */
> + len = strlen(line);
> +
> /* Unwrap transfer encoding */
> len = decode_transfer_encoding(line, sizeof(line), len);
> if (len < 0) {
This does fix the "F\n" issue, but seems to break t5100 test ("respect
NULs"). I haven't looked into the details yet...
^ permalink raw reply
* Re: finding deleted file names
From: Geoff Russell @ 2008-07-07 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Mikael Magnusson, git
In-Reply-To: <7v63rjpp4s.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 6, 2008 at 2:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
>> On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>>>
>>> > ... I've made a bunch of changes to a repository, a few weeks later I
>>>
>>> > figure I've deleted a file I need but am not really sure of its name. So
>>> > I want to list the files that I've deleted during the past few weeks.
>>>
>>>
>>> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days
>>
>> This is good, but on my version 1.5.5.1, is giving the commit-ids +
>> comments as well
>> as the names.
>
> Oh, I very much intended to give them, as --since=90.days is very broad
> that you would want to know which exact commit to learn when the found
> change was made anyway.
>
That's fine, the --name-only confused me, but I understand what is
happening now.
Geoff.
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-07 1:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LSU.1.00.0807061309140.32725@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 6 Jul 2008, Junio C Hamano wrote:
>
>> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
>> + apply --root: thinkofix.
>> + Teach "git apply" to prepend a prefix with "--root=<root>"
>
> If we want to call this "--directory=<root>" instead, we should do it
> before that commit hits master.
Yeah, perhaps like this?
-- >8 --
git-apply --directory: make --root more similar to GNU diff
Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff. The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-apply.txt | 8 ++++++--
builtin-apply.c | 4 ++--
t/t4128-apply-root.sh | 8 ++++----
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 63fce53..3cd3179 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -14,7 +14,7 @@ SYNOPSIS
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
[--whitespace=<nowarn|warn|fix|error|error-all>]
- [--exclude=PATH] [--root=<root>] [--verbose] [<patch>...]
+ [--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...]
DESCRIPTION
-----------
@@ -177,9 +177,13 @@ behavior:
current patch being applied will be printed. This option will cause
additional information to be reported.
---root=<root>::
+--directory=<root>::
Prepend <root> to all filenames. If a "-p" argument was passed, too,
it is applied before prepending the new root.
++
+For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
+can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
+running `git apply --directory=modules/git-gui`.
Configuration
-------------
diff --git a/builtin-apply.c b/builtin-apply.c
index 6c3db60..c242bbd 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3130,8 +3130,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
inaccurate_eof = 1;
continue;
}
- if (!prefixcmp(arg, "--root=")) {
- arg += strlen("--root=");
+ if (!prefixcmp(arg, "--directory=")) {
+ arg += strlen("--directory=");
root_len = strlen(arg);
if (root_len && arg[root_len - 1] != '/') {
char *new_root;
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index b650245..2dd0c75 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -23,18 +23,18 @@ diff a/bla/blub/dir/file b/bla/blub/dir/file
+Bello
EOF
-test_expect_success 'apply --root -p (1)' '
+test_expect_success 'apply --directory -p (1)' '
- git apply --root=some/sub -p3 --index patch &&
+ git apply --directory=some/sub -p3 --index patch &&
test Bello = $(git show :some/sub/dir/file) &&
test Bello = $(cat some/sub/dir/file)
'
-test_expect_success 'apply --root -p (2) ' '
+test_expect_success 'apply --directory -p (2) ' '
git reset --hard initial &&
- git apply --root=some/sub/ -p3 --index patch &&
+ git apply --directory=some/sub/ -p3 --index patch &&
test Bello = $(git show :some/sub/dir/file) &&
test Bello = $(cat some/sub/dir/file)
^ permalink raw reply related
* Re: git-clone --quiet broken?
From: Daniel Barkalow @ 2008-07-07 1:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Dave Jones, git
In-Reply-To: <20080706225649.GD17659@steel.home>
On Mon, 7 Jul 2008, Alex Riesen wrote:
> While at it, could we please have the first "Initialize" message
> removed?
>
> Initialize git/.git
> Initialized empty Git repository in /home/davej/git-trees/git/.git/
>
> The default output looks redundant (that of init_db too, but the full
> path can be useful sometimes). Something like this, perhaps:
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 643c7d4..4a0f1ab 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -421,7 +421,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> die("could not create leading directories of '%s'", git_dir);
> set_git_dir(make_absolute_path(git_dir));
>
> - fprintf(stderr, "Initialize %s\n", git_dir);
> init_db(option_template, option_quiet ? INIT_DB_QUIET : 0);
>
> /*
Yeah, that's clearly left-over debugging, and I think that's the only one
left from this conversion, anyway.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid calling syslog() from a signal handler
From: Junio C Hamano @ 2008-07-07 1:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, git
In-Reply-To: <alpine.LSU.1.00.0807061414320.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Note that we still have to check for dead children in
> check_max_connections(), and since child_handler() knows nothing
> about that, it still will write to the pipe, waking up the loop
> unnecessarily.
>
> But that will be rare.
>
> This is no longer as trivial as I wanted it to be, so I'd
> appreciate a few eyeballs on this patch.
Yeah, I think the fix-up I sent on top of your patch to make 1-sec timeout
conditional would be more appropriate for 'maint' than this one, even
though it is a band-aid to the issue.
Another thing we might want to consider to make this logic much more
simpler would be to move everything out of child_handler(), except the
write() whose sole purpose is to allow us break out of the poll().
Then you do not have to use "negative is error and positive is success"
convention (which you may regret later when you would need to pass more
than one bit of information from the callsite of waitpid() to the callsite
of syslog()), nor separate "reap here, report there" code structure.
^ permalink raw reply
* Re: [PATCH] INSTALL: Update section about git-frotz form.
From: Junio C Hamano @ 2008-07-07 2:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, git
In-Reply-To: <alpine.LSU.1.00.0807061312520.32725@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sun, 6 Jul 2008, Miklos Vajna wrote:
>
>> + Let's face it, most of us don't have GNU interactive tools, and even
>> + if we had it, we wouldn't know what it does. I don't think it has
>> + been actively developed since 1997, and people have moved over to
>
> This: ^ ^ ^ ^ ^ ^ ^ ^ ^
>
> ... and this:
>
>> + In addition, as of gnuit-4.9.2, the GNU interactive tools package has
>> + been renamed.
>
> somehow contradict each other. Maybe kill the whole sentence containing
> 1997?
The mention of 1997 was correct when it was made, and I think it still is
true to some extent (http://savannah.gnu.org/forum/forum.php?forum_id=5189
says it has not been actively maintained for quite some time), but I think
it is no longer relevant to us whether many users use gnuit or moved away
to graphical file managers because of its name change.
The only people possibly affected are people who has older version of
gnuit that has been called git, so how about shortening the section even
further like:
INSTALL | 26 +++++++++-----------------
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/INSTALL b/INSTALL
index 4a4e13f..7d0c2c2 100644
--- a/INSTALL
+++ b/INSTALL
@@ -24,23 +24,15 @@ set up install paths (via config.mak.autogen), so you can write instead
Issues of note:
- - git normally installs a helper script wrapper called "git", which
- conflicts with a similarly named "GNU interactive tools" program.
-
- Tough. Either don't use the wrapper script, or delete the old GNU
- interactive tools. None of the core git stuff needs the wrapper,
- it's just a convenient shorthand and while it is documented in some
- places, you can always replace "git commit" with "git-commit"
- instead.
-
- But let's face it, most of us don't have GNU interactive tools, and
- even if we had it, we wouldn't know what it does. I don't think it
- has been actively developed since 1997, and people have moved over to
- graphical file managers.
-
- NOTE: As of gnuit-4.9.2, the GNU interactive tools package has been
- renamed. You can compile gnuit with the --disable-transition
- option and then it will not conflict with git.
+ - Ancient versions of GNU Interactive Tools (pre-4.9.2) installed a
+ program "git", whose name conflicts with this program. But with
+ version 4.9.2, after long hiatus without active maintenance (since
+ around 1997), it changed its name to gnuit and the name conflict is no
+ longer a problem.
+
+ NOTE: When compiled with backward compatiblity option, the GNU
+ Interactive Tools package still can install "git", but you can build it
+ with --disable-transition option to avoid this.
- You can use git after building but without installing if you
wanted to. Various git commands need to find other git
^ permalink raw reply related
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Dmitry Potapov @ 2008-07-07 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <7vbq1ad4nn.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
> > git rev-list 7ac749c^@..7ac749c
> > fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path
> > not in the working tree.
> >
> > yet "^rev^@ rev" syntax does:
> >
> > git rev-list ^7ac749c^@ 7ac749c
> > 7ac749c96d143ba4f76723959892cbaddbe8ed07
> >
> > Is it a bug or feature?
> >
> > Puzzled...
>
> After reading these paragraphs from "SPECIFYING RANGES":
>
> History traversing commands such as 'git-log' operate on a set
> of commits, not just a single commit. To these commands,
> specifying a single revision with the notation described in the
> previous section means the set of commits reachable from that
> commit, following the commit ancestry chain.
>
> To exclude commits reachable from a commit, a prefix `{caret}`
> notation is used. E.g. "`{caret}r1 r2`" means commits reachable
> from `r2` but exclude the ones reachable from `r1`.
>
> This set operation appears so often that there is a shorthand
> for it. "`r1..r2`" is equivalent to "`{caret}r1 r2`". It is
> the difference of two sets (subtract the set of commits
> reachable from `r1` from the set of commits reachable from
> `r2`).
>
> it is obvious to me that the third paragraph talks about r1 that is a
> single rev (refer to SPECIFYING REVISIONS section, which does _NOT_ talk
> about rev^@ nor rev^!) and r2 that similarly is another single rev. So I
> think it is fairly clear that your "r^@..r" example is nonsense.
I think both second and third paragraphs talk about r1 as a single
revision. Yet, it is allowed to use "^r^@ r", and it works fine while
you cannot use "r^@..r". Of course, this behavior does not contradict
documentation, as it says _nothing_ about what will happen if you use
"r^@" instead of r1. That is why asked whether it is a bug or feature.
It still escapes me though, why you consider "r^@..r" as nonsense while
"^r^@ r" as correct syntax. Not that I am trying to argue with how it
should work, but I am just trying to understand your logic here.
Dmitry
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Junio C Hamano @ 2008-07-07 4:43 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1215379370-34265-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> This makes rebase act a little more like merge when working on the
> current branch. This is particularly useful for `git pull --rebase`
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
> ARG! This is what v3 was supposed to be. I should make sure I am sending in
> the correct patch.
Yeah, I was scratching my head about the discrepancy between the revision
comment and the patch in the previous one.
Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
useful information these days, so I do not see much practical upside, even
though I _will_ apply this patch, just for the sake of consistency.
We would make it _appear_ rebase and merge are interchangeable even more.
But the thing is, I am not convinced if promoting that appearance is
necessarily a good thing.
You now do not have to say something like:
After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
what are new, but 'git pull --rebase' is different and you would
say 'git diff branch@{1}.." instead.
and you can tell the users that ORIG_HEAD can be used in both cases.
But you cannot say the same thing with "gitk ORIG_HEAD..", for example.
The meaning of the topology and commits you would see would be quite
different. For rebase you will see your own commits that are carried
forward, and for merge you won't. Besides this example, there probably
are many fundamental differences between rebase and merge, and trying to
give a false impression that they are interchangeable may not add much
value to the end user experience, and it could even be harmful from
educational point of view.
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-07 5:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v7iby9ucx.fsf@gitster.siamese.dyndns.org>
On Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:
> Having said that, thanks to updates to git-rebase,
> rebased_branch@{1} has
> useful information these days, so I do not see much practical
> upside, even
> though I _will_ apply this patch, just for the sake of consistency.
I've been running rebase a lot over the last few days, and my
impression was that git-rebase adds an entry to ther eflog for each
patch it runs over. While this has its uses, it makes HEAD@{1} not
terribly useful after a "pull --rebase". Of course, it took me three
tries to get a one-line patch out this weekend, so my judgement is
obviously not that great at the moment.
I do appreciate that you'll apply it though. As useful as I find
rebasing pull useful, I dislike maintaining patches on top of git. It
tends to lead to something breaking when I don't have time to fix
it. ;-)
> We would make it _appear_ rebase and merge are interchangeable even
> more.
> But the thing is, I am not convinced if promoting that appearance is
> necessarily a good thing.
I don't really think promoting it is a good idea, actually. I do,
however, think that having ORIG_HEAD set intelligently after a pull
is. I nearly added setting ORIG_HEAD to pull, but didn't think that
removing it from merge or setting it twice was a good plan.
Besides, I've done the wrong rebase more than once and having the
quick recovery is excellent. (Reflogs are great, but when the commit
messages are identical it becomes a little difficult to figure out
which one to use.)
> But you cannot say the same thing with "gitk ORIG_HEAD..", for
> example.
> The meaning of the topology and commits you would see would be quite
> different. For rebase you will see your own commits that are carried
> forward, and for merge you won't. Besides this example, there
> probably
> are many fundamental differences between rebase and merge, and
> trying to
> give a false impression that they are interchangeable may not add much
> value to the end user experience, and it could even be harmful from
> educational point of view.
However, the rebased patches may have changed in subtle ways, so
having them appear in gitk is a good thing. If I was trying to teach
someone git, I'd compare the rebased commits to the merge commit.
They both give information on how any conflicts were resolved
(although the information is more subtle with rebase).
My final thought is that the rational ORIG_HEAD and when we set it is
not clearly documented anywhere. But I am currently out of time to
work on git, so that patch won't be coming from me soon.
~~ Brian
^ permalink raw reply
* Re: [PATCH] git-mailinfo may corrupt patch headers on attached files
From: Junio C Hamano @ 2008-07-07 5:19 UTC (permalink / raw)
To: Don Zickus; +Cc: git, torvalds
In-Reply-To: <1215379261-10802-1-git-send-email-dzickus@redhat.com>
Don Zickus <dzickus@redhat.com> writes:
> @@ -814,6 +814,9 @@ static void handle_body(void)
> return;
> }
>
> + /* line may have changed after handling boundary, check len */
> + len = strlen(line);
> +
> /* Unwrap transfer encoding */
> len = decode_transfer_encoding(line, sizeof(line), len);
> if (len < 0) {
Sorry, but I have to reject this. The reason this function treats "len"
in an unnatural way is that you cannot do strlen(line) if you want to
handle patches that touch lines with embedded NUL in them. Ideally, the
array line[] in the global scope should be replaced with a pair of "char
line[] and int linelen" (or strbuf) so that the code will always know how
long the line is, but the conversion done by cce8d6f (mailsplit and
mailinfo: gracefully handle NUL characters, 2008-05-16) and 9aa2309
(mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths,
2008-05-25) were done in minimally invasive way, so not all codepath in
the program can deal with lines with embedded NULs. For that reason, the
code still uses fgets() and strlen() everywhere, but the two patches
quoted above should be careful enough to allow NULs in the contents part
of the message (structural parts such as mime boundaries cannot have NUL
with the code, but it should not be a problem in practice).
The point you inserted strlen() above, however, is one of the places that
line[] has patch text and can have NUL in it, so strlen() there would
break the earlier fix.
Here is the minimum replacement patch, still not handling embedded NULs
anywhere in the structural part of the message, that should work. Sane
MUAs should quote embedded NULs in the original contents with QP or BASE64
to protect them from handle_boundary() and other functions, and after
decoding, these embedded NULs will be kept by decode_transfer_encoding(),
so I think this would work Ok in practice.
I tested this with both Linus's test message and it does not break t5100.
---
builtin-mailinfo.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 97c1ff9..fa6e8f9 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -812,6 +812,7 @@ static void handle_body(void)
np - newline);
if (!handle_boundary())
return;
+ len = strlen(line);
}
/* Unwrap transfer encoding */
^ permalink raw reply related
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Junio C Hamano @ 2008-07-07 5:24 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <803A3528-2451-4C5D-A48D-5E0C37B8E90E@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:
>
>> Having said that, thanks to updates to git-rebase,
>> rebased_branch@{1} has
>> useful information these days, so I do not see much practical
>> upside, even
>> though I _will_ apply this patch, just for the sake of consistency.
>
> I've been running rebase a lot over the last few days, and my
> impression was that git-rebase adds an entry to ther eflog for each
> patch it runs over. While this has its uses, it makes HEAD@{1} not
> terribly useful after a "pull --rebase".
Actually, I was not talking about HEAD@{1}. Check the reflog of the
branch you rebased, i.e.
$ git checkout bg/rebase
$ git rebase master
$ git diff bg/rebase@{1} bg/rebase
If you have two patches in bg/rebase, HEAD@{2} will be the updated master,
HEAD@{1} will be the first patch on top of it, and HEAD will be the
rebased tip. bg/rebase@{1} on the other hand is the tip of bg/rebase
before you started rebasing (i.e. the result of "git checkout bg/rebase"
above).
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Mike Hommey @ 2008-07-07 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <7v7iby9ucx.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
> > This makes rebase act a little more like merge when working on the
> > current branch. This is particularly useful for `git pull --rebase`
> >
> > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > ---
> >
> > ARG! This is what v3 was supposed to be. I should make sure I am sending in
> > the correct patch.
>
> Yeah, I was scratching my head about the discrepancy between the revision
> comment and the patch in the previous one.
>
> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> useful information these days, so I do not see much practical upside, even
> though I _will_ apply this patch, just for the sake of consistency.
>
> We would make it _appear_ rebase and merge are interchangeable even more.
> But the thing is, I am not convinced if promoting that appearance is
> necessarily a good thing.
>
> You now do not have to say something like:
>
> After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
> what are new, but 'git pull --rebase' is different and you would
> say 'git diff branch@{1}.." instead.
>
> and you can tell the users that ORIG_HEAD can be used in both cases.
And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.
Mike
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Junio C Hamano @ 2008-07-07 5:46 UTC (permalink / raw)
To: Mike Hommey; +Cc: Brian Gernhardt, Git List
In-Reply-To: <20080707054105.GB9737@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:
> ...
>> We would make it _appear_ rebase and merge are interchangeable even more.
>> But the thing is, I am not convinced if promoting that appearance is
>> necessarily a good thing.
>>
>> You now do not have to say something like:
>>
>> After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
>> what are new, but 'git pull --rebase' is different and you would
>> say 'git diff branch@{1}.." instead.
>>
>> and you can tell the users that ORIG_HEAD can be used in both cases.
>
> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.
No you cannot. Read what I wrote again. I never said HEAD@{1} ;-)
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Mike Hommey @ 2008-07-07 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <20080707054105.GB9737@glandium.org>
On Mon, Jul 07, 2008 at 07:41:05AM +0200, Mike Hommey wrote:
> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:
> > Brian Gernhardt <benji@silverinsanity.com> writes:
> >
> > > This makes rebase act a little more like merge when working on the
> > > current branch. This is particularly useful for `git pull --rebase`
> > >
> > > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > > ---
> > >
> > > ARG! This is what v3 was supposed to be. I should make sure I am sending in
> > > the correct patch.
> >
> > Yeah, I was scratching my head about the discrepancy between the revision
> > comment and the patch in the previous one.
> >
> > Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> > useful information these days, so I do not see much practical upside, even
> > though I _will_ apply this patch, just for the sake of consistency.
> >
> > We would make it _appear_ rebase and merge are interchangeable even more.
> > But the thing is, I am not convinced if promoting that appearance is
> > necessarily a good thing.
> >
> > You now do not have to say something like:
> >
> > After a 'git pull' you can view 'git diff ORIG_HEAD..' to check
> > what are new, but 'git pull --rebase' is different and you would
> > say 'git diff branch@{1}.." instead.
> >
> > and you can tell the users that ORIG_HEAD can be used in both cases.
>
> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.
Forget it, I just woke up, I'm writing crap.
Mike
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Nanako Shiraishi @ 2008-07-07 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <7v7iby9ucx.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> This makes rebase act a little more like merge when working on the
>> current branch. This is particularly useful for `git pull --rebase`
>>
>> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
>> ---
>>
>> ARG! This is what v3 was supposed to be. I should make sure I am sending in
>> the correct patch.
>
> Yeah, I was scratching my head about the discrepancy between the revision
> comment and the patch in the previous one.
>
> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has
> useful information these days, so I do not see much practical upside, even
> though I _will_ apply this patch, just for the sake of consistency.
Are you really aiming for consistency, Junio?
Doesn't this make the behavior of the command inconsistent between "git-rebase" and "git-rebase -m"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-07 6:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Lars Hjemli, Ping Yin, Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807061821340.7342@eeepc-johanness>
> IOW the mail body should look like the output of format-patch, optionally
> some comments between "--" and the diffstat.
>
> Write a patch for SubmittingPatches.
I shall do that :)
> > > Not yet. Will test/comment when the spurious "fetch" is fixed.
> >
> > I thought that the only thing that 'fetch' does is update FETCH_HEAD.
>
> Uhoh. 'fetch' fetches. Which means it does not only update something.
Yes, it fetches objects (admittedly, it updates something on the current
partition), but AFAIK does not change the state of the repository. So I thought
that it could be considered as a no-op from the repo point of view. The idea
behind the 'fetch' thing was to get the latest objects from the repository,
therefore being able to know the relationship between the currently committed
submodule state
> There are three states that are interesting:
>
> - the committed submodule state:
>
> You get this in the superproject by "git ls-tree HEAD -- <dir>"
>
> - the local HEAD of the submodule:
>
> (cd "<dir>" && git rev-parse --verify HEAD)
>
> - the HEAD of the default branch of the upstream repository of the
> submodule:
>
> (cd "<dir>" && git ls-remote origin HEAD)
> NOTE: this does not have to do _anything_ with the submodule: you can
> easily have two independent branches (see "html" and "next" in git.git),
> and the submodule is free to be pinned to whatever commit is available
> in the upstream repository.
>
> It is even possible that it is pinned to a commit that is only reachable
> from a tag, not from a branch.
Then when you initialize your submodules it will be unable to fetch the commit
object, isn't it ? Since git-submodule clones origin/HEAD, the submodule state
committed in the repository must be reachable from origin/HEAD.
Or the third interesting state is not "the default branch of the upstream
repository of the submodule", i.e. origin/HEAD, but the
most-probably-interesting-branch, i.e. the branch configured in .git/config as
being fetched for the current branch of the local submodule HEAD.
That is the point of this patch. It make clear, *for all registered submodules*,
what is the current relationship between the current submodule state committed
in the repository and the current submodule HEAD. The "fetch" is there to take
into account the fact that the submodule state may not yet be available locally.
Best,
--
Sylvain
^ 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