* Re: quilt/0.46-1 misbehaviour...
From: Johannes Schindelin @ 2007-11-20 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matti Aarnio, git
In-Reply-To: <7vve7xl97g.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Nov 2007, Junio C Hamano wrote:
> Va bgure jbeqf, junk qbrf guvf unir gb qb jvgu tvg???
Did you not mean "jung" instead of "junk"?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] send-email: add transfer encoding header with content-type
From: Jeff King @ 2007-11-20 12:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Junio C Hamano, git, Brian Swetland, Russell King - ARM Linux,
Nicolas Pitre
In-Reply-To: <20071119104950.GB8645@informatik.uni-freiburg.de>
We add the content-type header only when we have non-7bit
characters from the 'From' header, so we really need to
specify the encoding (in other cases, where the commit text
needed a content-type, git-format-patch will already have
added the encoding header).
Signed-off-by: Jeff King <peff@peff.net>
---
On Mon, Nov 19, 2007 at 11:49:50AM +0100, Uwe Kleine-König wrote:
> but no Content-Transfer-Encoding:. This yield a 7bit mail with 8bit
> characters.
>
> I think we should add
>
> Content-Transfer-Encoding: 8bit
Even though Brian's mail turned out to be hand-generated, this problem
does exist in git-send-email. I don't know why I didn't add the encoding
header in the first place, since it is clearly required.
Junio, I think this is maint-worthy.
git-send-email.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fd0a4ad..d7b8391 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -781,7 +781,8 @@ foreach my $t (@files) {
else {
push @xh,
'MIME-Version: 1.0',
- "Content-Type: text/plain; charset=$author_encoding";
+ "Content-Type: text/plain; charset=$author_encoding",
+ 'Content-Transfer-Encoding: 8bit';
}
}
}
--
1.5.3.6.1784.gd1b1d-dirty
^ permalink raw reply related
* Re: [user] git-svn and svn cp
From: gerhard.oettl.ml @ 2007-11-20 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <20071119162612.GA10122@soma>
Eric Wong schrieb:
> gerhard.oettl.ml@ogersoft.at wrote:
>> Does svn-git dont know about lightweight svn copies?
> Older versions of the Perl SVN bindings have a broken do_switch()
> SVN 1.4.4+ has this fix which allows do_switch() to be used
Thanks this sadisfies my question and its time to dive deeper into git
and git-svn ...
gerhard
^ permalink raw reply
* Re: [PATCH] send-email: add transfer encoding header with content-type
From: Uwe Kleine-König @ 2007-11-20 13:49 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Brian Swetland, Russell King - ARM Linux,
Nicolas Pitre
In-Reply-To: <20071120125404.GB7998@sigill.intra.peff.net>
Hello,
Jeff King wrote:
> We add the content-type header only when we have non-7bit
> characters from the 'From' header, so we really need to
> specify the encoding (in other cases, where the commit text
> needed a content-type, git-format-patch will already have
> added the encoding header).
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
--
Uwe Kleine-König
$ dc << EOF
[d1-d1<a]sa99d1<a1[rdn555760928P*pz1<a]salax
EOF
^ permalink raw reply
* stgit: another way of storing patches
From: Jon Smirl @ 2007-11-20 14:53 UTC (permalink / raw)
To: Git Mailing List
What about storing each stg git patch in a branch and then
auto-merging them into the working copy? That would allow per patch
history and undo. Would it make them easier to share? You could use
tag names to tell stg how to merge and make the working branch.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Johannes Sixt @ 2007-11-20 16:17 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1195503174-29387-1-git-send-email-pkufranky@gmail.com>
Ping Yin schrieb:
> This patch disables the auto closing behavious of start_command
> and corrects all codes which depend on this kind of behaviour.
I've thought about this a bit more, and I think that it is better to leave
this auto-closing behavior unchanged and change your usage of this feature,
like so:
> +static void wt_status_print_submodule_summary(struct wt_status *s)
> +{
> + struct child_process sm_summary;
> + memset(&sm_summary, 0, sizeof(sm_summary));
> + ...
> + sm_summary.out = fileno(s->fp);
fflush(s->fp);
sm_summary.out = dup(fileno(s->fp)); /* run_command closes it */
> + ...
> + run_command(&sm_summary);
> +}
This way the change is more local without affecting well-tested other callers.
Furthermore, I don't think that it's correct to just set the .close_in or
.close_out flags. This will close the fd only in finish_command(), which can
be too late: Think again of a writable pipe end that remains open and keeps
the reader waiting for input that is not going to happen.
-- Hannes
^ permalink raw reply
* Partial checkouts / submodules
From: Finn Arne Gangstad @ 2007-11-20 15:59 UTC (permalink / raw)
To: git
My use case it this: We have some huge projects (let's call them
supermodules) that are the only products we really release. Any change
going into any of the submodules go in solely to modify the
superproject, the submodules are not released on their own.
We cannot keep the supermodule with all its submodules in one git
repository for two reasons: Size & sharing. A 6GB+ repository is too
big to handle gracefully, and there are multiple superprojects sharing
some of the submodules. Our supermodules typically contains 50-250
submodules. Usually it is sufficient to look at just a few of these
submodules at the same time.
I looked into the current git submodules to see if they support what I
think we need, but it seems like they do not really cut it (If I'm
wrong about this, please educate me).
What I want is this:
Somewhere the following modules all exist:
supermodule/
submodule1
submodule2
submodule3
...
submodule200
You pull the supermodule, and initialize random collection of
submodules, e.g. locally you have:
supermodule/
submodule13
submodule71
submodule102
Now I want this to behave as if it was a partial checkout of
"supermodule" - i.e. I want _all_ operations in any of the submodules
to act as if they happened in all the submodules (as if supermodule
was a single repository containing all the submodules directly).
If I do a change in submodule13, another change in submodule71 and yet
another change in submodule102, I want to be able to commit them all
as ONE commit (obviously it will be 4 commits, 1 in each submodule and
one in the supermodule, but anyone looking at this in the context of
this supermodule should see it as one commit).
If I pull supermodule, I get updates to supermodule, submodule13,
submodule71 and submodule102, but nothing else.
If I make a branch on submodule71, the branch is made in all submodules &
the supermodule.
With this setup it should be possible to handle supermodule as a
normal module with branches for each feature/topic/bugfix, and those
features being merged into other branches in a reasonable way. Does
something like this look doable?
- Finn Arne
^ permalink raw reply
* RE: git-daemon
From: Medve Emilian @ 2007-11-20 16:54 UTC (permalink / raw)
To: git
In-Reply-To: <20071120050756.GA29502@sigill.intra.peff.net>
Hi Jeff,
I just built and installed the latest master (and next) and then I tried
to clone (as I usualy do) one of my repositories. I run git-daemon only
with the upload-pack service enabled.
On the client side this is the symptom:
client:~> git-clone git://server/srv/scm/linux-2.6.git
Initialized empty Git repository in /home/user/linux-2.6/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 'git://server/srv/scm/linux-2.6.git' failed.
On the server side I get this message:
xined.log:
07/11/20@10:17:04: START: git from=10.82.124.104
07/11/20@10:17:04: EXIT: git status=255 duration=0(sec)
messages:
Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
10.82.124.104:2978
Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended attributes (18
bytes) exist <host=server>
Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request upload-pack for
'/srv/scm/linux-2.6.git'
And here is a small tcpdump snippet:
10:25:09.817726 IP client.msfrs > server.git: S 1311107296:1311107296(0)
win 65535 <mss 1260,nop,nop,sackOK>
10:25:09.817820 IP server.git > client.msfrs: S 3324794408:3324794408(0)
ack 1311107297 win 5840 <mss 1460,nop,nop,sackOK>
10:25:09.818028 IP client.msfrs > server.git: . ack 1 win 65535
10:25:09.817726 IP (tos 0x0, ttl 128, id 16243, offset 0, flags [DF],
proto: TCP (6), length: 48) client.msfrs > server.git: S, cksum 0x093b
(correct), 1311107296:1311107296(0) win 65535 <mss 1260,nop,nop,sackOK>
10:25:09.817820 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 48) server.git > client.msfrs: S, cksum 0xd53c
(correct), 33247944
08:3324794408(0) ack 1311107297 win 5840 <mss 1460,nop,nop,sackOK>
10:25:09.818028 IP (tos 0x0, ttl 128, id 16244, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: ., cksum 0x18d1
(correct), 1:1(0) ack 1 win 65535
10:25:09.819114 IP (tos 0x0, ttl 128, id 16246, offset 0, flags [DF],
proto: TCP (6), length: 102) client.msfrs > server.git: P 1:63(62) ack 1
win 65535
10:25:09.819159 IP (tos 0x0, ttl 64, id 14907, offset 0, flags [DF],
proto: TCP (6), length: 40) server.git > client.msfrs: ., cksum 0x01c3
(correct), 1:1(0) ack 63 win 5840
10:25:09.819114 IP client.msfrs > server.git: P 1:63(62) ack 1 win 65535
10:25:09.819159 IP server.git > client.msfrs: . ack 63 win 5840
10:25:09.821531 IP server.git > client.msfrs: F 1:1(0) ack 63 win 5840
10:25:09.821531 IP (tos 0x0, ttl 64, id 14908, offset 0, flags [DF],
proto: TCP (6), length: 40) server.git > client.msfrs: F, cksum 0x01c2
(correct), 1:1(0) ack 63 win 5840
10:25:09.821769 IP (tos 0x0, ttl 128, id 16248, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: ., cksum 0x1892
(correct), 63:63(0) ack 2 win 65535
10:25:09.821769 IP client.msfrs > server.git: . ack 2 win 65535
10:25:09.826015 IP client.msfrs > server.git: F 63:63(0) ack 2 win 65535
10:25:09.826040 IP server.git > client.msfrs: . ack 64 win 5840
10:25:09.826015 IP (tos 0x0, ttl 128, id 16249, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: F, cksum 0x1891
(correct), 63:63(0) ack 2 win 65535
10:25:09.826040 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 40) server.git > client.msfrs: ., cksum 0x01c1
(correct), 2:2(0) ack 64 win 5840
I'm not sure what other details would be relevant: tools versions,
kernel version?
Did you try this and is working for you?
Cheers,
Emil.
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jeff King
> Sent: Monday, November 19, 2007 11:08 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
>
> On Mon, Nov 19, 2007 at 03:49:36PM -0700, Medve Emilian wrote:
>
> > v1.5.3.6 works but the HEAD of master and next don't. I
> considered the
> > patches below but they seemed harmless. I think the problem
> comes form
> > upload-pack (and below it). Weirdly enough running
> git-daemon standalone
> > seems to work fine. Cloning over ssh or on the same file
> system seems to
> > work fine too.
> >
> > I was hoping somebody can repeat the experiment (build the
> latest master
> > or maint) and invalidate my experience.
>
> I can't find any breakage on the current master (ea559605). Can you be
> more specific about what you are trying, how it is breaking, other
> details of your setup, etc?
>
> -Peff
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Guido Ostkamp @ 2007-11-20 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, Björn Steinbrink, raa.lkml, git
In-Reply-To: <7vhcjhl3ni.fsf@gitster.siamese.dyndns.org>
Hello Junio,
On Tue, 20 Nov 2007, Junio C Hamano wrote:
> I knew it would work on Solaris with gcc and cc that do not understand
> flexible array members, but I am a bit worried about other environments,
> where flexible array members are properly supported. They've been
> happily using member[] but with the patch they suddenly start wasting a
> cell.
>
> But we should do this sooner rather than later to find out any breakage,
> and give people on platforms with a cc that supports flexible array
> members and care about wasted memory enough time to send patches to
> support their compiler in the way similar to how gcc is supported.
>
> But I cannot use your message with whitespace-broken patch (note
> "format=flawed") and insufficient commit log message, which means I have
> to do this myself. Not tonight...
sorry for the whitespace-issues. I have attached the patch again with
improved log message and will turn off format-flawed for this email.
Please let me know if this one is ok and feel free to fix it.
Log message starts here:
Fix "identifier redeclared" compilation error with SUN cc.
The problem is caused by incomplete arrays like
struct foo {
...
char last_member_that_is_flexible[];
}
which cannot be handled by certain compilers.
The solution is to change the last member to either
char last_member_that_is_flexible[0]
or
char last_member_that_is_flexible[1]
as required. Currently GNU CC can handle [] format for
version 3 and later. Earlier versions need [0].
Non-GNU compiler use the safe form [1].
Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
---
git-compat-util.h | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 276a437..97759fd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -4,11 +4,20 @@
#define _FILE_OFFSET_BITS 64
#ifndef FLEX_ARRAY
-#if defined(__GNUC__) && (__GNUC__ < 3)
+#if defined(__GNUC__)
+#if (__GNUC__ < 3)
#define FLEX_ARRAY 0
#else
#define FLEX_ARRAY /* empty */
#endif
+#else
+/* more cases we know we can use 0 or empty can come here */
+#endif
+#endif
+
+/* if still undefined, default to the safe, old fashioned way */
+#ifndef FLEX_ARRAY
+#define FLEX_ARRAY 1
#endif
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
--
1.5.3.6.728.gea559
^ permalink raw reply related
* Re: Partial checkouts / submodules
From: Sven Verdoolaege @ 2007-11-20 17:33 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20071120155922.GA6271@pvv.org>
On Tue, Nov 20, 2007 at 04:59:22PM +0100, Finn Arne Gangstad wrote:
> I looked into the current git submodules to see if they support what I
> think we need, but it seems like they do not really cut it (If I'm
> wrong about this, please educate me).
Maybe you could explain why you think they don't cut it.
> You pull the supermodule, and initialize random collection of
> submodules, e.g. locally you have:
>
> supermodule/
> submodule13
> submodule71
> submodule102
Just "submodule init" and "submodule update" these submodules and
it looks like you would get what you want...
> If I make a branch on submodule71, the branch is made in all submodules &
> the supermodule.
... except this one.
It's not clear why you would even want this.
skimo
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 18:03 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20071120155922.GA6271@pvv.org>
On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
> My use case it this: We have some huge projects (let's call them
> supermodules) that are the only products we really release. Any change
> going into any of the submodules go in solely to modify the
> superproject, the submodules are not released on their own.
>
> We cannot keep the supermodule with all its submodules in one git
> repository for two reasons: Size & sharing. A 6GB+ repository is too
> big to handle gracefully, and there are multiple superprojects sharing
> some of the submodules. Our supermodules typically contains 50-250
> submodules. Usually it is sufficient to look at just a few of these
> submodules at the same time.
>
> I looked into the current git submodules to see if they support what I
> think we need, but it seems like they do not really cut it (If I'm
> wrong about this, please educate me).
>
> What I want is this:
>
> Somewhere the following modules all exist:
>
> supermodule/
> submodule1
> submodule2
> submodule3
> ...
> submodule200
>
> You pull the supermodule, and initialize random collection of
> submodules, e.g. locally you have:
>
> supermodule/
> submodule13
> submodule71
> submodule102
>
> Now I want this to behave as if it was a partial checkout of
> "supermodule" - i.e. I want _all_ operations in any of the submodules
> to act as if they happened in all the submodules (as if supermodule
> was a single repository containing all the submodules directly).
>
> If I do a change in submodule13, another change in submodule71 and yet
> another change in submodule102, I want to be able to commit them all
> as ONE commit (obviously it will be 4 commits, 1 in each submodule and
> one in the supermodule, but anyone looking at this in the context of
> this supermodule should see it as one commit).
This has theoretical problems: it's going to be practically impossible, in
most cases, to write a commit message that describes changes in three
submodules (which are sometimes used in the context of a different
supermodule) as well as the supermodule.
On the other hand, the supermodule commit is the one that's relevant in
the context of the supermodule, and that commit's message should describe
the set of changes as a whole.
I think it should be possible and sufficient to have "git commit" able to
recursively start a "git commit" in submodules (where you'd write a
separate message suitable for exposure to other supermodules), so you'd
have to write 4 messages but only type one command line.
> If I pull supermodule, I get updates to supermodule, submodule13,
> submodule71 and submodule102, but nothing else.
This should work. Of course, if other people have made changes to parts of
the supermodule that you haven't checked out, your supermodule index will
reflect those changes, so that supermodule commits you make aren't
reverting or removing those submodules. But you won't fetch the contents
of those submodules, and won't have them checked out. (Note, however,
that, if you pull from two places, each of which has changed the same
submodule you don't have in a different way, you'll get a conflict you
can't resolve without getting the submodule yourself or getting somebody
else to merge them; git won't let you make commits which leave the
submodule merge for somebody who cares)
> If I make a branch on submodule71, the branch is made in all submodules &
> the supermodule.
I don't think this aspect has been worked out too carefully. I think the
branch is made only in the supermodule, but the submodules are attached to
the supermodule's index, rather than particularly using branches, and so,
when the supermodule switches branches, the submodules should all follow,
regardless of whether they have explicit branches.
> With this setup it should be possible to handle supermodule as a
> normal module with branches for each feature/topic/bugfix, and those
> features being merged into other branches in a reasonable way. Does
> something like this look doable?
AFAIK, supermodules haven't gotten heavy enough use to work out all of the
details of what should happen when the user does different things. I think
it's all doable, but you may have to convince people to actually do it,
and I don't think everything yet works the way you'd want.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Guido Ostkamp @ 2007-11-20 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711201823460.4280@bianca.dialin.t-online.de>
> sorry for the whitespace-issues. I have attached the patch again with
> improved log message and will turn off format-flawed for this email.
only for the list: I noticed another whitespace problem and have meanwhile
sent the patch to Junio as true attachment of a private email because I do
not know whether attachments are accepted on this list (most likely they
are not). Sorry for the inconvenience.
Regards
Guido
^ permalink raw reply
* Re: [PATCH] autoconf: Add tests for memmem, strtoumax and mkdtemp functions
From: Stefan-W. Hahn @ 2007-11-20 18:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <7vd4u5l29v.fsf@gitster.siamese.dyndns.org>
Also sprach Junio C Hamano am Tue, 20 Nov 2007 at 01:00:44 -0800:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > By the way, do you have idea how to test for the following
> > in configure.ac:
> >
> > * Define NO_PREAD if you have a problem with pread() system call (e.g.
> > cygwin.dll before v1.5.22).
> >
> > - what is the problem? how to detect it?
>
> 6900679c2f6d937a5a6ef616869c8887690ad19d (Replacing the system
> call pread() with lseek()/xread()/lseek() sequence.)
>
For me it happened when using git (e.g. git commit). Detecting perhaps
is possible with "cygcheck" command which shows the version of cygwin
system dlls.
Perhaps: cygcheck -p 'cygwin1.dll'
Shows name and version of found cygwin1.dll.
Stefan
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Finn Arne Gangstad @ 2007-11-20 18:19 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20071120173350.GA2261MdfPADPa@greensroom.kotnet.org>
On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:
> Just "submodule init" and "submodule update" these submodules and
> it looks like you would get what you want...
>
> > If I make a branch on submodule71, the branch is made in all submodules &
> > the supermodule.
>
> ... except this one.
> It's not clear why you would even want this.
I'll try to boil this down to the simplest case possible. If
submodules can do this I'll be really happy :)
Developer A makes a change in submodule1 and in submodule2
Developer B makes a change in submodule2 and in submodule3
A and B don't know about eachother. They send their modifications
somewhere (push to a shared repository with a well chosen branch name,
for example), or send a mail "please pull from my repo" to the patch
queue manager.
It is absolutely crucial that for each developer, either both their
modifications go in, or none of them. Git should make picking only
one of their modifications hard.
Also - it would be very good if the history in the master repo would
match the history in all developers' repositories (as the
modifications are merged in by the patch queue manager). I.e. - you
should see a "gif support" feature branch, see the commits on it, and
finally the merge.
- Finn Arne
^ permalink raw reply
* Re: [PATCH 1/2] send-pack: cluster ref status reporting
From: Alex Riesen @ 2007-11-20 18:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071120111801.GA7814@sigill.intra.peff.net>
Jeff King, Tue, Nov 20, 2007 12:18:01 +0100:
> Instead of intermingling success and failure, we now print:
>
> 1. all uptodate refs (if args.verbose is enabled)
> 2. successfully pushed refs
> 3. failed refs
I vote for this. The non-ff refs clustered together was the real
reason behind my beautification patch.
> I am somewhat ambivalent on this patch. In most cases, it won't make a
> difference, since the output is small enough. For large pushes, it might
> be better to have errors at the end. OTOH, you do still get "error:
> failed to push to ..." at the end, and you can scroll up and see the
> errors if you like. And it's not like preserving the original ref output
> order was all that interesting.
It is just simplier to distinguish visually: non-ff's are formatted
significantly different. You don't even have to read what is written
to immediately notice if there are problems.
^ permalink raw reply
* Re: [PATCH 2/2] send-pack: print "maybe you need to pull" hint
From: Alex Riesen @ 2007-11-20 18:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071120112146.GB7814@sigill.intra.peff.net>
Jeff King, Tue, Nov 20, 2007 12:21:46 +0100:
> If there were refs rejected for not being fastforwards, then
> we used to print a "maybe you are not up-to-date" hint. This
> was lost in the recent terse-output patches.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I am slightly negative on this patch, just because I always found that
> particular warning a bit ugly (and the new output is so nice and
> compact). But for new users, perhaps the extra hint is helpful?
Dunno. It's kind of dumb hint and it takes lots of space. I was even
thinking about hint(const char *,...), which can be configured to
compile out in Makefile.
^ permalink raw reply
* Re: git-daemon
From: Jeff King @ 2007-11-20 18:26 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27017BCD50@az33exm24.fsl.freescale.net>
On Tue, Nov 20, 2007 at 09:54:13AM -0700, Medve Emilian wrote:
> I just built and installed the latest master (and next) and then I tried
> to clone (as I usualy do) one of my repositories. I run git-daemon only
> with the upload-pack service enabled.
> [...]
>
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
> 10.82.124.104:2978
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended attributes (18
> bytes) exist <host=server>
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request upload-pack for
> '/srv/scm/linux-2.6.git'
I don't see anything useful there. Have you tried running git-daemon
with --verbose? If that doesn't turn up anything, can you try running
with GIT_TRACE=1 to see the upload pack command that is being executed
(and try running it yourself)?
> Did you try this and is working for you?
Yes, it works fine (though I ran it under tcpserver, not xinetd).
-Peff
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Steven Grimm @ 2007-11-20 18:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Finn Arne Gangstad, git
In-Reply-To: <Pine.LNX.4.64.0711201226320.32410@iabervon.org>
On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:
> This has theoretical problems: it's going to be practically
> impossible, in
> most cases, to write a commit message that describes changes in three
> submodules (which are sometimes used in the context of a different
> supermodule) as well as the supermodule.
I got the impression from his email that there *are* no other
supermodules. The submodules are submodules purely to reduce the
amount of data people have to transfer around, not because they're
logically distinct from the parent.
Something like "Fix bug #10391 by closing the data file before
launching the GUI" or something like that would be just as valid a
commit comment in the submodules here as it would be in the
supermodules.
Sounds like what he wants is actually partial checkout, but since git
doesn't (yet) support that, he's emulating it as best he can using
submodules.
> I think it should be possible and sufficient to have "git commit"
> able to
> recursively start a "git commit" in submodules (where you'd write a
> separate message suitable for exposure to other supermodules), so
> you'd
> have to write 4 messages but only type one command line.
If the message in the submodule defaulted to the one from the
supermodule, and there was a way to just accept it without popping up
an editor N times, this might solve his problem.
-Steve
^ permalink raw reply
* [PATCH] Improve documentation of git-filter-branch rev-list specification.
From: Carl Worth @ 2007-11-20 18:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The rev-list is not optional, and a range of a..b will not rewrite
only b. Fix these errors and improve the wording of surrounding text.
Also eliminate the discussion of using no filters to compensate for
hypothetical future bugs. It's not helpful.
---
Documentation/git-filter-branch.txt | 34 ++++++++++++++++++++--------------
1 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ba9b4fb..985d7d5 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -13,23 +13,29 @@ SYNOPSIS
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--subdirectory-filter <directory>]
[--original <namespace>] [-d <directory>] [-f | --force]
- [<rev-list options>...]
+ <rev-list options>...
DESCRIPTION
-----------
-Lets you rewrite git revision history by rewriting the branches mentioned
-in the <rev-list options>, applying custom filters on each revision.
-Those filters can modify each tree (e.g. removing a file or running
-a perl rewrite on all files) or information about each commit.
-Otherwise, all information (including original commit times or merge
-information) will be preserved.
-
-The command will only rewrite the _positive_ refs mentioned in the
-command line (i.e. if you pass 'a..b', only 'b' will be rewritten).
-If you specify no filters, the commits will be recommitted without any
-changes, which would normally have no effect. Nevertheless, this may be
-useful in the future for compensating for some git bugs or such,
-therefore such a usage is permitted.
+Rewrites git revision history by applying one or more filters to a set
+of commits. The set of commits to be rewritten is supplied in
+<rev-list options> and can be as simple as one or more branch names,
+(in which case all commits reachable from those branch names will be
+rewritten).
+
+The filters can modify the tree content stored in each commit,
+(e.g. removing a file or running a perl rewrite on all files), or the
+associated information about each commit, (commit message, author,
+parent, etc.). Any information not affected by a filter (including
+original commit times or merge information) will be preserved. If you
+specify no filters, the commits will be recommitted without any
+changes.
+
+Note that passing a range of commits specified with the a..b notation
+will rewrite 'b' and all commits reachable from 'b' but not reachable
+from 'a', but will not rewrite the commit 'a' itself. This is
+consistent with the handling of a range by git-log and other git
+commands.
*WARNING*! The rewritten history will have different object names for all
the objects and will not converge with the original branch. You will not
--
1.5.3.4
^ permalink raw reply related
* Re: quilt/0.46-1 misbehaviour...
From: Alex Riesen @ 2007-11-20 18:34 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071120055149.GQ6372@mea-ext.zmailer.org>
Matti Aarnio, Tue, Nov 20, 2007 06:51:49 +0100:
> .. or perhaps Exim, but odd result in arriving and thus outgoing headers anyway.
>
...
> Diagnostic-Code: smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
>
> From: clameter@sgi.com
> From: Christoph Lameter <clameter@sgi.com>
> To: ak@suse.de
> Cc: akpm@linux-foundation.org
> Cc: travis@sgi.com
> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Cc: linux-kernel@vger.kernel.org
...
> Remote-MTA: dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|39031)
> Last-Attempt-Date: Mon, 19 Nov 2007 20:17:31 -0500
> Diagnostic-Code: smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
...
> Date: Mon, 19 Nov 2007 17:11:41 -0800
> Subject: [rfc 09/45] cpu alloc: IA64 support
> From: clameter@sgi.com
> From: Christoph Lameter <clameter@sgi.com>
> Message-Id: <20071120011333.850453474@sgi.com>
Is this the problem: duplicate From: and quadriplicate Cc:?
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 18:36 UTC (permalink / raw)
To: Steven Grimm; +Cc: Finn Arne Gangstad, git
In-Reply-To: <1AD9B065-647B-4672-B6B0-8D4447960913@midwinter.com>
On Tue, 20 Nov 2007, Steven Grimm wrote:
> On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:
> >This has theoretical problems: it's going to be practically impossible, in
> >most cases, to write a commit message that describes changes in three
> >submodules (which are sometimes used in the context of a different
> >supermodule) as well as the supermodule.
>
> I got the impression from his email that there *are* no other supermodules.
> The submodules are submodules purely to reduce the amount of data people have
> to transfer around, not because they're logically distinct from the parent.
He said:
"there are multiple superprojects sharing some of the submodules."
Getting the effect of partial checkouts was the first-listed reason, but
not the only one. The submodules don't make sense except in the context of
some supermodule, but there are multiple contexts they each appear in.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Sven Verdoolaege @ 2007-11-20 18:42 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20071120181932.GA20705@pvv.org>
On Tue, Nov 20, 2007 at 07:19:33PM +0100, Finn Arne Gangstad wrote:
> On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:
>
> > Just "submodule init" and "submodule update" these submodules and
> > it looks like you would get what you want...
> >
> > > If I make a branch on submodule71, the branch is made in all submodules &
> > > the supermodule.
> >
> > ... except this one.
> > It's not clear why you would even want this.
>
> I'll try to boil this down to the simplest case possible. If
> submodules can do this I'll be really happy :)
>
> Developer A makes a change in submodule1 and in submodule2
> Developer B makes a change in submodule2 and in submodule3
I'm assuming that A and B also make a commit to the supermodule
incorporating their changes to the submodules (as in your
original message).
> A and B don't know about eachother. They send their modifications
> somewhere (push to a shared repository with a well chosen branch name,
> for example), or send a mail "please pull from my repo" to the patch
> queue manager.
The commit A made to the superproject contains his changes
to the submodule, so if someone pulls this superproject commit,
she'll get the submodule changes too.
(Although she may choose not to have some or all of these
submodules checked out.)
> Also - it would be very good if the history in the master repo would
> match the history in all developers' repositories (as the
> modifications are merged in by the patch queue manager). I.e. - you
> should see a "gif support" feature branch, see the commits on it, and
> finally the merge.
You can't change the history in git. [*1]
It's still not clear why you would want new branches to be created
in other modules when you create a new branch in some module.
skimo
[*1] There are tools that allow you to create a new history based
on an old history, but it will be a different history.
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Martin Mares @ 2007-11-20 18:26 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Junio C Hamano, Björn Steinbrink, raa.lkml, git
In-Reply-To: <Pine.LNX.4.64.0711191847550.7957@bianca.dialin.t-online.de>
Hello!
> #ifndef FLEX_ARRAY
> -#if defined(__GNUC__) && (__GNUC__ < 3)
> +#if defined(__GNUC__)
> +#if (__GNUC__ < 3)
> #define FLEX_ARRAY 0
> #else
> #define FLEX_ARRAY /* empty */
> #endif
> +#else
> +/* more cases we know we can use 0 or empty can come here */
> +#endif
> +#endif
> +
> +/* if still undefined, default to the safe, old fashioned way */
> +#ifndef FLEX_ARRAY
> +#define FLEX_ARRAY 1
> #endif
Do we really want to use empty FLEX_ARRAY only for a new gcc? Shouldn't
we test for C99 instead (__STDC_VERSION__ >= 199901L) and only if it
isn't C99, choose between 0 and 1 depending on gccness of the compiler?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"First they ignore you. Then they laugh at you. Then they fight you. Then you win." -- Gandhi
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Sergei Organov @ 2007-11-20 18:55 UTC (permalink / raw)
To: Steven Grimm; +Cc: Daniel Barkalow, Finn Arne Gangstad, git
In-Reply-To: <1AD9B065-647B-4672-B6B0-8D4447960913@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> On Nov 20, 2007, at 10:03 AM, Daniel Barkalow wrote:
>> This has theoretical problems: it's going to be practically
>> impossible, in
>> most cases, to write a commit message that describes changes in three
>> submodules (which are sometimes used in the context of a different
>> supermodule) as well as the supermodule.
>
> I got the impression from his email that there *are* no other
> supermodules. The submodules are submodules purely to reduce the
> amount of data people have to transfer around, not because they're
> logically distinct from the parent.
I got the same impression, and then I wonder if the next logical thing
the OP will need is, say, support for content moves between
submodules. Somehow I doubt git will ever support that.
--
Sergei.
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 18:59 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: skimo, git
In-Reply-To: <20071120181932.GA20705@pvv.org>
On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
> On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:
>
> > Just "submodule init" and "submodule update" these submodules and
> > it looks like you would get what you want...
> >
> > > If I make a branch on submodule71, the branch is made in all submodules &
> > > the supermodule.
> >
> > ... except this one.
> > It's not clear why you would even want this.
>
> I'll try to boil this down to the simplest case possible. If
> submodules can do this I'll be really happy :)
>
> Developer A makes a change in submodule1 and in submodule2
> Developer B makes a change in submodule2 and in submodule3
>
> A and B don't know about eachother. They send their modifications
> somewhere (push to a shared repository with a well chosen branch name,
> for example), or send a mail "please pull from my repo" to the patch
> queue manager.
>
> It is absolutely crucial that for each developer, either both their
> modifications go in, or none of them. Git should make picking only
> one of their modifications hard.
This is the case; if developer A changes 2 from 2-O to 2-A, and developer
B changes 2 from 2-O to 2-B, merging both supermodule commits gets a
conflict, which requires a merge in submodule 2 before the supermodule
merge can be committed.
On the other hand, 3-B will sort of enter the history of submodule 3
without the submodule 2 merge getting done; however, there's no way for
anybody to find it if it's not referenced by any supermodule commit yet
and people don't look at the individual histories of submodules.
One thing that might be an issue is that, if developer A of supermodule I
makes a commit that changes submodule 1 and submodule 2, and developer B
on supermodule II decides to merge supermodule I's submodule 1, and
supermodule II also includes submodule 2, but developer B doesn't care
about it, supermodule II could end up with only half of developer A's
change.
> Also - it would be very good if the history in the master repo would
> match the history in all developers' repositories (as the
> modifications are merged in by the patch queue manager). I.e. - you
> should see a "gif support" feature branch, see the commits on it, and
> finally the merge.
This is independant of submodule support, and depends on the patch queue
manager's policy. In some cases, it's desirable to simplify the history of
the feature branch when it's being merged into the master repo, so that
the master repo gets an idealized version of the feature branch (i.e.,
bugs introduced early in the development of the branch and fixed later,
but never affected the master repo, are not introduced in the first place;
also, the historical accident of the work on the topic being started
before other features but completed after them can be smoothed over, with
the resolution of merge conflicts distributed back to the sites where the
second set of changes was made). If the patch queue manager does this sort
of thing, the master repo's history will be different from the feature
branch's history as it appeared to the developers at the time, but the
feature branch also generally goes away at this point anyway, so it
doesn't matter too much.
-Daniel
*This .sig left intentionally blank*
^ 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