* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Erik Faye-Lund @ 2010-01-16 10:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001161144.55263.j6t@kdbg.org>
On Sat, Jan 16, 2010 at 11:44 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Samstag, 16. Januar 2010, Erik Faye-Lund wrote:
>> On Sat, Jan 16, 2010 at 9:08 AM, Johannes Sixt <j6t@kdbg.org> wrote:
>> > Wouldn't it be possible to call getsockopt(), and if it returns ENOTSOCK
>> > (WSAENOTSOCK), then it is a pipe?
>>
>> I read reports that this didn't work in Wine. Not that I care that
>> much about Wine.
>
> What does it mean that "it does not work"? Is it that it does not return
> ENOTSOCK, so that we mistake pipes as sockets?
>
> -- Hannes
>
Yes, according to the gnulib sources[1], getsockopt returns 0 for pipes.
[1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/poll.c;h=90d99d92dca5d7ce2f31097e4b8fc06a83aae245;hb=HEAD#l80
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Fix bad quoting in documentation
From: Ramkumar Ramachandra @ 2010-01-16 11:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201001161120.14846.trast@student.ethz.ch>
Hi,
> If not, please tell the debian guys to set ASCIIDOC8=YesPlease when
> building the docs.
Thanks! The Makefile clearly points this out. I'll let the Debian people know.
-- Ram
^ permalink raw reply
* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Erik Faye-Lund @ 2010-01-16 11:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001161138.36535.j6t@kdbg.org>
On Sat, Jan 16, 2010 at 11:38 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Samstag, 16. Januar 2010, Erik Faye-Lund wrote:
>> On Sat, Jan 16, 2010 at 9:06 AM, Johannes Sixt <j6t@kdbg.org> wrote:
>> > On Samstag, 16. Januar 2010, Erik Faye-Lund wrote:
>> >> +static inline void mingw_fd_set(int fd, fd_set *set)
>> >> +{
>> >> + FD_SET(_get_osfhandle(fd), set);
>> >> +}
>> >> #undef FD_SET
>> >> +#define FD_SET(a,b) mingw_fd_set(a,b)
>> >> +
>> >> #undef FD_ISSET
>> >> #define FD_ISSET(fd, set) __WSAFDIsSet(_get_osfhandle(fd), (fd_set
>> >> *)(set))
>> >
>> > Ah, yes, how obvious ;) You are going to do the same with FD_ISSET as
>> > well, aren't you?
>>
>> Do I really need to? There's already a single function for that, with
>> no "ugly hidden internals" there; __WSAFDIsSet() is documented in
>> MSDN. I mean, Sure... I could... I just don't see the point.
>
> __WSAFDIsSet is "ugly hidden internals" and we should not rely on it when we
> can use the official FD_ISSET for our own FD_ISSET.
>
> -- Hannes
>
...but __WSAFDIsSet() seems to be every bit as official on Windows as
FD_ISSET() (documented in msdn, without any notes not to use it), so I
still don't really see the point.
However, I don't personally care one way or the other, so just doing
it is probably less work than convincing you that I don't have to ;)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Andreas Schwab @ 2010-01-16 11:27 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, msysgit, git
In-Reply-To: <40aa078e1001160305y17b46a6dtc4959e5255c7acae@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> ...but __WSAFDIsSet() seems to be every bit as official on Windows as
> FD_ISSET() (documented in msdn, without any notes not to use it), so I
> still don't really see the point.
The fact that it starts with two underscores suggests that it is kinda
internal.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Erik Faye-Lund @ 2010-01-16 11:43 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Johannes Sixt, msysgit, git
In-Reply-To: <m26372uw5k.fsf@igel.home>
(Note: I'll argue only for the sake for the argument here, I've
already pretty much decided to follow Hannes' suggestion)
On Sat, Jan 16, 2010 at 12:27 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> The fact that it starts with two underscores suggests that it is kinda
> internal.
>
But the fact that it is documented more than suggests that it isn't.
Not any more, anyhow. This is pretty much how winapi works. Internal
stuff isn't documented, once it's documented it isn't internal
anymore. In fact, winapi doesn't really deal with "internal" and
"external" functions, it deals with documented and undocumented. Some
documented functions/features have documented compatibility issues.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Fix bad quoting in documentation
From: Teemu Likonen @ 2010-01-16 11:58 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Thomas Rast, git
In-Reply-To: <f3271551001160300m24932ad4wfd72abc826f2bb65@mail.gmail.com>
On 2010-01-16 16:30 (+0530), Ramkumar Ramachandra wrote:
>> If not, please tell the debian guys to set ASCIIDOC8=YesPlease when
>> building the docs.
>
> Thanks! The Makefile clearly points this out. I'll let the Debian
> people know.
Git 1:1.6.6-1 in Debian's unstable repository is built with
ASCIIDOC8=YesPlease and ASCIIDOC_NO_ROFF=Yes options.
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 12:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263633827-23720-1-git-send-email-ilari.liusvaara@elisanet.fi>
Hi,
On Sat, 16 Jan 2010 11:23:47 +0200
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> [snip]
> @@ -218,6 +218,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
> OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
> OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
> OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
> + OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
This line exceeds 80 characters.
Also, I think you should follow the case-style of the other option
descriptions and s/Set(?= upstream)/set/.
> [snip]
> +static void set_upstreams(struct transport *trans, struct ref *refs,
I would prefer if you could follow the naming convention and say
"transport" instead of truncating to "trans".
> + int pretend)
> +{
> + struct ref *i;
> + for (i = refs; i; i = i->next) {
In most places, "ref" instead of "i" is used; ie.
struct ref *ref;
for (ref = refs; ref; ref = ref->next) {
..
}
> [snip]
> + /*
> + * Check suitability for tracking. Must be successful /
> + * alreay up-to-date ref create/modify (not delete).
> + */
s/alreay/already/.
> [snip]
> + /* Chase symbolic refs (mainly for HEAD). */
Did you mean "Change" here?
Regarding the checking of ref->status here:
> @@ -135,6 +136,53 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
> }
> }
>
> [snip]
> + if (i->status != REF_STATUS_OK &&
> + i->status != REF_STATUS_UPTODATE)
> + continue;
Is it possible to delegate this to push_had_errors(remote_refs)
instead? We skip setting up upstream tracking when there are errors
from pushing, so we don't have to check ref->status anymore.
(Note: this would skip setting up upstream when ref->status is 'none',
in addition to 'ok' and 'uptodate', as you have it right now. I think
this should be safe.)
@@ -1002,8 +1055,9 @@ int transport_push(struct transport *transport,
verbose | porcelain, porcelain,
nonfastforward);
- if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
- set_upstreams(transport, remote_refs, pretend);
+ if (!push_had_errors(remote_refs) &&
+ (flags & TRANSPORT_PUSH_SET_UPSTREAM))
+ set_upstreams(transport, remote_refs, pretend);
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
for (ref = remote_refs; ref; ref = ref->next)
(As a side note, if you apply this on top of 'tr/http-push-ref-status'
in 'pu', the result of push_had_errors() is saved in a variable
('err'), so you could just use it and not have to call push_had_errors
() again.)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Johannes Sixt @ 2010-01-16 12:36 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git
In-Reply-To: <40aa078e1001160305y17b46a6dtc4959e5255c7acae@mail.gmail.com>
On Samstag, 16. Januar 2010, Erik Faye-Lund wrote:
> ...but __WSAFDIsSet() seems to be every bit as official on Windows as
> FD_ISSET() (documented in msdn, without any notes not to use it), so I
> still don't really see the point.
I didn't know nor check whether it is documented, but assumed from the '__'
that it must be internal. Being documented makes a big difference. I'm fine
with either solution.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] difftool: Add '-x' and as an alias for '--extcmd'
From: Bill Lear @ 2010-01-16 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, git
In-Reply-To: <7vbpguoo4y.fsf@alter.siamese.dyndns.org>
On Friday, January 15, 2010 at 17:05:17 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>
>> On Friday, January 15, 2010 at 11:46:32 (-0800) Junio C Hamano writes:
>>>David Aguilar <davvid@gmail.com> writes:
>>>
>>>> -# Copyright (c) 2009 David Aguilar
>>>> +# Copyright (c) 2009-2010 David Aguilar
>>>
>>>Just a very minor issue. I'd prefer to see:
>>>
>>> Copyright (c) 2008, 2009, 2010
>>>
>>>over
>>>
>>> Copyright (c) 2008-2010
>>
>> Why?
>
>I learned this from <http://www.gnu.org/licenses/gpl-howto.html>. The
>advice doesn't say _why_, but my understanding of the rationale behind it
>is that the international convention that governs this copyright
>notice specifically mentions "the year of publication", not "range of
>years" (UCC Geneva text, Sept. 06, 1952, Article III 1.).
>
>Berne convention does not require such a copyright notice, and many
>countries are signatories of both treaties, so the whole copyright notice
>may be a moot point in many countries, but it matters in some. As long as
>the file (and the GNU advice cited above) is being cautious by having the
>notice, it would be better to be equally cautious and spell the years of
>publication out.
>
>But I am not a lawyer.
Hmm, interesting. My wife is a lawyer, maybe I'll sic her on this.
My guess is that if this came to court, a judge would laugh at anyone
who tried to assert a meaningful difference.
Good to know though, thank you for taking the time to explain this.
Bill
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Ilari Liusvaara @ 2010-01-16 13:46 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <20100116203557.95340c00.rctay89@gmail.com>
On Sat, Jan 16, 2010 at 08:35:57PM +0800, Tay Ray Chuan wrote:
> Hi,
>
> On Sat, 16 Jan 2010 11:23:47 +0200
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > + OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
>
> This line exceeds 80 characters.
Broken into two (without breaking the message), it is still over 80.
> Also, I think you should follow the case-style of the other option
> descriptions and s/Set(?= upstream)/set/.
Fixed.
> > [snip]
> > +static void set_upstreams(struct transport *trans, struct ref *refs,
>
> I would prefer if you could follow the naming convention and say
> "transport" instead of truncating to "trans".
Fixed.
> > + struct ref *i;
> > + for (i = refs; i; i = i->next) {
>
> In most places, "ref" instead of "i" is used; ie.
Fixed.
> > + * alreay up-to-date ref create/modify (not delete).
>
> s/alreay/already/.
Fixed.
> > + /* Chase symbolic refs (mainly for HEAD). */
>
> Did you mean "Change" here?
No. Changed to 'Follow'.
> Regarding the checking of ref->status here:
>
> Is it possible to delegate this to push_had_errors(remote_refs)
> instead? We skip setting up upstream tracking when there are errors
> from pushing, so we don't have to check ref->status anymore.
No. As documetnation says, the update or no update is done on per-branch
basis.
<snip patch>
> (As a side note, if you apply this on top of 'tr/http-push-ref-status'
> in 'pu', the result of push_had_errors() is saved in a variable
> ('err'), so you could just use it and not have to call push_had_errors
> () again.)
See above.
I'll sit on v4 for some more time to wait for more comments.
-Ilari
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 15:30 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20100116134656.GA4504@Knoppix>
Hi,
On Sat, 16 Jan 2010 15:46:57 +0200
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > Regarding the checking of ref->status here:
> >
> > Is it possible to delegate this to push_had_errors(remote_refs)
> > instead? We skip setting up upstream tracking when there are errors
> > from pushing, so we don't have to check ref->status anymore.
>
> No. As documetnation says, the update or no update is done on per-branch
> basis.
>
> <snip patch>
I see. If that's the case, could you also allow setting up upstream
tracking when ref->status is 'none' and not consider it errorneous?
After all, push_had_errors() does not consider 'none' errorneous.
I think a switch block might be neater too.
@@ -149,9 +149,15 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
* Check suitability for tracking. Must be successful /
* already up-to-date ref create/modify (not delete).
*/
- if (ref->status != REF_STATUS_OK &&
- ref->status != REF_STATUS_UPTODATE)
+ switch (ref->status) {
+ case REF_STATUS_NONE:
+ case REF_STATUS_UPTODATE:
+ case REF_STATUS_OK:
+ ; /* no-op */
+ default:
continue;
+ }
if (!ref->peer_ref)
continue;
if (!ref->new_sha1 || is_null_sha1(ref->new_sha1))
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Ilari Liusvaara @ 2010-01-16 15:56 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <20100116233043.26a5636d.rctay89@gmail.com>
On Sat, Jan 16, 2010 at 11:30:43PM +0800, Tay Ray Chuan wrote:
> Hi,
>
> On Sat, 16 Jan 2010 15:46:57 +0200
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>
> > > Regarding the checking of ref->status here:
> > >
> > > Is it possible to delegate this to push_had_errors(remote_refs)
> > > instead? We skip setting up upstream tracking when there are errors
> > > from pushing, so we don't have to check ref->status anymore.
> >
> > No. As documetnation says, the update or no update is done on per-branch
> > basis.
> >
> > <snip patch>
>
> I see. If that's the case, could you also allow setting up upstream
> tracking when ref->status is 'none' and not consider it errorneous?
>
> After all, push_had_errors() does not consider 'none' errorneous.
Hmm... In what conditions ref->status is 'none' after push operation
has completed?
-Ilari
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 16:13 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20100116155612.GA8383@Knoppix>
Hi,
On Sat, Jan 16, 2010 at 11:56 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> Hmm... In what conditions ref->status is 'none' after push operation
> has completed?
when a match between a local and remote ref is not found.
For example, the local ref 'master' will match the remote ref
'master', but not 'retsam' ('master' spelled in reverse).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Junio C Hamano @ 2010-01-16 16:47 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Ilari Liusvaara, git
In-Reply-To: <20100116233043.26a5636d.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> + switch (ref->status) {
> + case REF_STATUS_NONE:
> + case REF_STATUS_UPTODATE:
> + case REF_STATUS_OK:
> + ; /* no-op */
> + default:
> continue;
> + }
Could somebody document what these values (and what "struct ref" has in
general) mean in the transport API documentation?
^ permalink raw reply
* git rm --cached and pull semantics
From: list @ 2010-01-16 16:50 UTC (permalink / raw)
To: git
Hello everyone,
I'm trying to manage and distribute a subset of /etc with git.
Therefore, I have * in .gitignore and use git add -f to add files. Now
sometimes I want to un-track a file that has been in previous commits,
but naturally I don't want the file deleted. I just want git to ignore
it again. As I read it, the way to do that is "git rm --cached $file".
On the local working tree, that works as expected, but when some remote
machine pulls a subsequent commit, it deletes the file from its working
tree. But I just want git to ignore the file again, just as it does in
the origin repo. How can I do that?
thanks for your time
^ permalink raw reply
* Re: [PATCH] Update documentation: git-commit is not a shell command
From: Junio C Hamano @ 2010-01-16 17:31 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <f3271551001160135k569e2692i5e2ab893701e1738@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> diff --git a/Documentation/gitcore-tutorial.txt
> b/Documentation/gitcore-tutorial.txt
> index f762dca..ebc5d0b 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -454,14 +454,7 @@ will be pruned out, and the rest will be used as
> the commit message for
> the change. If you decide you don't want to commit anything after all at
> this point (you can continue to edit things and update the index), you
> can just leave an empty message. Otherwise `git commit` will commit
> -the change for you.
> -
> -You've now made your first real git commit. And if you're interested in
> -looking at what `git commit` really does, feel free to investigate:
> -it's a few very simple shell scripts to generate the helpful (?) commit
> -message headers, and a few one-liners that actually do the
> -commit itself ('git-commit').
> -
> +the change for you. You've now made your first real git commit.
While the issue you are addressing may be a valid one, removing the whole
paragraph and not doing anything else is not an improvement. Read the
changed text in a larger context and you will notice that the tutorial
sequence around there does not make much sense anymore.
The point of the core tutorial is to introduce the reader to the low level
structure and plumbing, and a major reason for running "git commit" at
that point in the tutorial is to mention that what even a relatively high
level command "git commit" does can be scripted. Up to that point, the
tutorial showed a much lower level tools to create a commit, and said
"... but you've done that once already, so let's just use the helpful
script this time:" (by the way, you forgot to change this "script").
So after "You've now made your first real git commit" (which is not true,
by the way---the reader has already done so with commit-tree), you would
need to mention that what git-commit does can be scripted, that it indeed
was a script before Git v1.5.4, that if you want to write a command that
makes a commit but in a different way then you can script it using the
same ingredients the scripted "git commit" used to use, and perhaps that
the scripted version is available as a reference in the git source tree in
contrib/examples.
Actually, I changed my mind. There are many other Porcelain commands in
the core tutorial that are no longer scripted. It is better to leave the
main text of the tutorial as-is. In the initial part of the document,
mention that many Porcelain commands were scripts back when the document
was written, that the document uses them as examples of how plumbing are
fit together to form them, that some scripted Porcelain implementations
are found in contrib/examples/ directory of the source tree for reference
purposes, and that the description of what the plumbing layer commands do
in the document is still valid even though the Porcelain commands mentined
in the document are not implemented in terms of the plumbing commands in
shell scripts anymore.
^ permalink raw reply
* [PATCH v2 0/2] Show submodules as modified when they contain a dirty work tree
From: Jens Lehmann @ 2010-01-16 17:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Lars Hjemli, Nanako Shiraishi
Here is the updated version of the two patches.
This fixes all issues raised and passes the test suite.
Jens Lehmann (1):
Show submodules as modified when they contain a dirty work tree
Junio C Hamano (1):
Teach diff that modified submodule directory is dirty
diff-lib.c | 8 +++-
diff.c | 9 ++++-
submodule.c | 49 +++++++++++++++++++++++++
submodule.h | 1 +
t/t4027-diff-submodule.sh | 84 ++++++++++++++++++++++++++++++++++++++++++-
t/t7506-status-submodule.sh | 83 ++++++++++++++++++++++++++++++++++--------
6 files changed, 214 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] Show submodules as modified when they contain a dirty work tree
From: Jens Lehmann @ 2010-01-16 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Lars Hjemli, Nanako Shiraishi
In-Reply-To: <4B51F9EB.5090202@web.de>
Until now a submodule only then showed up as modified in the supermodule
when the last commit in the submodule differed from the one in the index
or the diffed against commit of the superproject. A dirty work tree
containing new untracked or modified files in a submodule was
undetectable when looking at it from the superproject.
Now git status and git diff (against the work tree) in the superproject
will also display submodules as modified when they contain untracked or
modified files, even if the compared ref matches the HEAD of the
submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Changed since the last version:
- Added missing include (spotted by Junio)
- Made test 7506 more robust (thanks to Nanako)
- When diffing the work tree against a commit in the supermodule the
submodule did not show up as modified when the refs matched
diff-lib.c | 8 +++-
submodule.c | 49 +++++++++++++++++++++++++
submodule.h | 1 +
t/t7506-status-submodule.sh | 83 +++++++++++++++++++++++++++++++++++--------
4 files changed, 124 insertions(+), 17 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 274ff8c..29c5915 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -10,6 +10,7 @@
#include "cache-tree.h"
#include "unpack-trees.h"
#include "refs.h"
+#include "submodule.h"
/*
* diff-files
@@ -159,7 +160,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
- if (ce_uptodate(ce) || ce_skip_worktree(ce))
+ if ((ce_uptodate(ce) && !S_ISGITLINK(ce->ce_mode)) || ce_skip_worktree(ce))
continue;
/* If CE_VALID is set, don't look at workdir for file removal */
@@ -176,6 +177,8 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
changed = ce_match_stat(ce, &st, ce_option);
+ if (S_ISGITLINK(ce->ce_mode) && !changed)
+ changed = is_submodule_modified(ce->name);
if (!changed) {
ce_mark_uptodate(ce);
if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
@@ -230,7 +233,8 @@ static int get_stat_data(struct cache_entry *ce,
return -1;
}
changed = ce_match_stat(ce, &st, 0);
- if (changed) {
+ if (changed
+ || (S_ISGITLINK(ce->ce_mode) && is_submodule_modified(ce->name))) {
mode = ce_mode_from_stat(ce, st.st_mode);
sha1 = null_sha1;
}
diff --git a/submodule.c b/submodule.c
index 86aad65..3f851de 100644
--- a/submodule.c
+++ b/submodule.c
@@ -4,6 +4,7 @@
#include "diff.h"
#include "commit.h"
#include "revision.h"
+#include "run-command.h"
int add_submodule_odb(const char *path)
{
@@ -112,3 +113,51 @@ void show_submodule_summary(FILE *f, const char *path,
}
strbuf_release(&sb);
}
+
+int is_submodule_modified(const char *path)
+{
+ int len;
+ struct child_process cp;
+ const char *argv[] = {
+ "status",
+ "--porcelain",
+ NULL,
+ };
+ char *env[3];
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "%s/.git/", path);
+ if (!is_directory(buf.buf)) {
+ strbuf_release(&buf);
+ /* The submodule is not checked out, so it is not modified */
+ return 0;
+
+ }
+ strbuf_reset(&buf);
+
+ strbuf_addf(&buf, "GIT_WORK_TREE=%s", path);
+ env[0] = strbuf_detach(&buf, NULL);
+ strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
+ env[1] = strbuf_detach(&buf, NULL);
+ env[2] = NULL;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = (const char *const *)env;
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.out = -1;
+ if (start_command(&cp))
+ die("Could not run git status --porcelain");
+
+ len = strbuf_read(&buf, cp.out, 1024);
+ close(cp.out);
+
+ if (finish_command(&cp))
+ die("git status --porcelain failed");
+
+ free(env[0]);
+ free(env[1]);
+ strbuf_release(&buf);
+ return len != 0;
+}
diff --git a/submodule.h b/submodule.h
index 4c0269d..0773121 100644
--- a/submodule.h
+++ b/submodule.h
@@ -4,5 +4,6 @@
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
const char *del, const char *add, const char *reset);
+int is_submodule_modified(const char *path);
#endif
diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh
index 3ca17ab..253c334 100755
--- a/t/t7506-status-submodule.sh
+++ b/t/t7506-status-submodule.sh
@@ -5,34 +5,87 @@ test_description='git status for submodule'
. ./test-lib.sh
test_expect_success 'setup' '
- test_create_repo sub
- cd sub &&
- : >bar &&
- git add bar &&
- git commit -m " Add bar" &&
- cd .. &&
- git add sub &&
+ test_create_repo sub &&
+ (
+ cd sub &&
+ : >bar &&
+ git add bar &&
+ git commit -m " Add bar" &&
+ : >foo &&
+ git add foo &&
+ git commit -m " Add foo"
+ ) &&
+ echo output > .gitignore &&
+ git add sub .gitignore &&
git commit -m "Add submodule sub"
'
test_expect_success 'status clean' '
- git status |
- grep "nothing to commit"
+ git status >output &&
+ grep "nothing to commit" output
'
+
test_expect_success 'commit --dry-run -a clean' '
- git commit --dry-run -a |
- grep "nothing to commit"
+ test_must_fail git commit --dry-run -a >output &&
+ grep "nothing to commit" output
+'
+
+test_expect_success 'status with modified file in submodule' '
+ (cd sub && git reset --hard) &&
+ echo "changed" >sub/foo &&
+ git status >output &&
+ grep "modified: sub" output
+'
+
+test_expect_success 'status with modified file in submodule (porcelain)' '
+ (cd sub && git reset --hard) &&
+ echo "changed" >sub/foo &&
+ git status --porcelain >output &&
+ diff output - <<-\EOF
+ M sub
+ EOF
+'
+
+test_expect_success 'status with added file in submodule' '
+ (cd sub && git reset --hard && echo >foo && git add foo) &&
+ git status >output &&
+ grep "modified: sub" output
+'
+
+test_expect_success 'status with added file in submodule (porcelain)' '
+ (cd sub && git reset --hard && echo >foo && git add foo) &&
+ git status --porcelain >output &&
+ diff output - <<-\EOF
+ M sub
+ EOF
+'
+
+test_expect_success 'status with untracked file in submodule' '
+ (cd sub && git reset --hard) &&
+ echo "content" >sub/new-file &&
+ git status >output &&
+ grep "modified: sub" output
+'
+
+test_expect_success 'status with untracked file in submodule (porcelain)' '
+ git status --porcelain >output &&
+ diff output - <<-\EOF
+ M sub
+ EOF
'
+
test_expect_success 'rm submodule contents' '
rm -rf sub/* sub/.git
'
+
test_expect_success 'status clean (empty submodule dir)' '
- git status |
- grep "nothing to commit"
+ git status >output &&
+ grep "nothing to commit" output
'
+
test_expect_success 'status -a clean (empty submodule dir)' '
- git commit --dry-run -a |
- grep "nothing to commit"
+ test_must_fail git commit --dry-run -a >output &&
+ grep "nothing to commit" output
'
test_done
--
1.6.6.332.g1985b
^ permalink raw reply related
* [PATCH v2 2/2] Teach diff that modified submodule directory is dirty
From: Jens Lehmann @ 2010-01-16 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Lars Hjemli, Nanako Shiraishi
In-Reply-To: <4B51F9EB.5090202@web.de>
From: Junio C Hamano <gitster@pobox.com>
A diff run in superproject only compares the name of the commit object
bound at the submodule paths. When we compare with a work tree and the
checked out submodule directory is dirty (e.g. has either staged or
unstaged changes, or has new files the user forgot to add to the index),
show the work tree side as "dirty".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Changed since the last version:
- I added 3 tests for "git diff HEAD" when refs match (the HEAD in the
submodule is the same as last committed in the superproject)
diff.c | 9 ++++-
t/t4027-diff-submodule.sh | 84 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 5060b48..012b3d3 100644
--- a/diff.c
+++ b/diff.c
@@ -2029,9 +2029,14 @@ static int populate_from_stdin(struct diff_filespec *s)
static int diff_populate_gitlink(struct diff_filespec *s, int size_only)
{
int len;
- char *data = xmalloc(100);
+ char *data = xmalloc(100), *dirty = "";
+
+ /* Are we looking at the work tree? */
+ if (!s->sha1_valid && is_submodule_modified(s->path))
+ dirty = "-dirty";
+
len = snprintf(data, 100,
- "Subproject commit %s\n", sha1_to_hex(s->sha1));
+ "Subproject commit %s%s\n", sha1_to_hex(s->sha1), dirty);
s->data = data;
s->size = len;
s->should_free = 1;
diff --git a/t/t4027-diff-submodule.sh b/t/t4027-diff-submodule.sh
index 5cf8924..83c1914 100755
--- a/t/t4027-diff-submodule.sh
+++ b/t/t4027-diff-submodule.sh
@@ -32,7 +32,8 @@ test_expect_success setup '
cd sub &&
git rev-list HEAD
) &&
- echo ":160000 160000 $3 $_z40 M sub" >expect
+ echo ":160000 160000 $3 $_z40 M sub" >expect &&
+ subtip=$3 subprev=$2
'
test_expect_success 'git diff --raw HEAD' '
@@ -50,6 +51,87 @@ test_expect_success 'git diff-files --raw' '
test_cmp expect actual.files
'
+expect_from_to () {
+ printf "%sSubproject commit %s\n+Subproject commit %s\n" \
+ "-" "$1" "$2"
+}
+
+test_expect_success 'git diff HEAD' '
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (work tree)' '
+ echo >>sub/world &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (index)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ echo >>world &&
+ git add world
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (untracked)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ git clean -qfdx &&
+ >cruft
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (work tree, refs match)' '
+ git commit -m "x" sub &&
+ echo >>sub/world &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (index, refs match)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ echo >>world &&
+ git add world
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (untracked, refs match)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ git clean -qfdx &&
+ >cruft
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
test_expect_success 'git diff (empty submodule dir)' '
: >empty &&
rm -rf sub/* sub/.git &&
--
1.6.6.332.g1985b
^ permalink raw reply related
* Integration-Manager Workflow
From: Adrián Ribao Martínez @ 2010-01-16 17:49 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 1907 bytes --]
Hello everybody, I'm learning git since I'm planning moving from Bazaar.
I've been reading the documentation and the progit book, which is excellent.
I'm a bit confused In the chapter: http://progit.org/book/ch5-1.html#integrationmanager_workflow : "Integration-Manager Workflow"
I need to manages a project with several developers. Those developers are split into teams.
I'm planning these:
* A central repository using the http protocol. This central repository would be only writable by myself, it would have http access for the developers and ssh access for me.
* Every team would have ssh access to their repositories. i.e. team1.myserver.net, team2.myserver.net
* I want at least three branches: master, test, and develop. The path would be: develop(development version) -> test (beta) -> master (stable)
* I don't want any developer to write into the develop branch, and if they do by mistake, I don't want to take it into account.
My question is about the branches in the teams repositories. I want the developers to create feature/fix branches in their checkouts and when they have finished the work, I check and merge into develop if everything is OK.
Is the following procedure correct?:
1. They send me the path of the branch I should do: git checkout --track origin/feature1 (where origin could be: ssh://user@team1.myserver.net:/home/user/git/project)
2. If everything is ok I merge into development and remove branch feature1.
3. They fetch and the branch is deleted in their local checkouts, and the feature1 is in the develop branch: git pull origin
What happens if they accidentally work in the develop branch instead of creating a new one? What should we do?
I think I should never fetch from teamx.myserver.net to avoid this problem and instead track the branch like in step 2. Is this correct?
Thank you for your help, I'm a bit confused about git.
Regards,
Adrian Ribao
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Documentation: Update git core tutorial clarifying reference to scripts
From: Ramkumar Ramachandra @ 2010-01-16 18:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Back when the git core tutorial was written, porcelain commands were
shell scripts. This patch adds a paragraph explaining this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/gitcore-tutorial.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt
b/Documentation/gitcore-tutorial.txt
index f762dca..cfc26c6 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -27,6 +27,14 @@ interfaces on top of it called "porcelain". You may
not want to use the
plumbing directly very often, but it can be good to know what the
plumbing does for when the porcelain isn't flushing.
+Back when this document was originally written, many porcelain
+commands were shell scripts. For simplicity, it still uses them as
+examples to illustrate how plumbing is fit together to form the
+porcelain commands. The source tree includes some of these scripts in
+contrib/examples/ for reference. Although these are not implemented as
+shell scripts anymore, the description of what the plumbing layer
+commands do is still valid.
+
[NOTE]
Deeper technical details are often marked as Notes, which you can
skip on your first reading.
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] Update documentation: git-commit is not a shell command
From: Ramkumar Ramachandra @ 2010-01-16 18:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wbyc5yb.fsf@alter.siamese.dyndns.org>
> Actually, I changed my mind. There are many other Porcelain commands in
> the core tutorial that are no longer scripted. It is better to leave the
> main text of the tutorial as-is. In the initial part of the document,
> mention that many Porcelain commands were scripts back when the document
> was written, that the document uses them as examples of how plumbing are
> fit together to form them, that some scripted Porcelain implementations
> are found in contrib/examples/ directory of the source tree for reference
> purposes, and that the description of what the plumbing layer commands do
> in the document is still valid even though the Porcelain commands mentined
> in the document are not implemented in terms of the plumbing commands in
> shell scripts anymore.
Right. Thanks for pointing that out. Here's the patch fixing it:
http://permalink.gmane.org/gmane.comp.version-control.git/137242
-- Ram
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 18:12 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <be6fef0d1001160813o674ed93dn33843813be6f45be@mail.gmail.com>
Hi,
On Sun, Jan 17, 2010 at 12:13 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hi,
>
> On Sat, Jan 16, 2010 at 11:56 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
>> Hmm... In what conditions ref->status is 'none' after push operation
>> has completed?
>
> when a match between a local and remote ref is not found.
>
> For example, the local ref 'master' will match the remote ref
> 'master', but not 'retsam' ('master' spelled in reverse).
I'd like to add that in this case ('none'), no data is pushed to the
remote repo.
This is true for 'uptodate' too, and shouldn't be taken as an error.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v2] Add push --set-upstream
From: Rudolf Polzer @ 2010-01-16 18:13 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Ilari Liusvaara, Junio C Hamano, Nanako Shiraishi,
Johannes Schindelin, Miles Bader, Martin Langhoff, git
In-Reply-To: <be6fef0d1001151700se963950i6932d30bae3ca940@mail.gmail.com>
On Sat, Jan 16, 2010 at 09:00:30AM +0800, Tay Ray Chuan wrote:
> Hi,
>
> I'm adding people from the "git push --track" thread here, since this
> feature is related to what they want.
>
> (sorry for any line-wrap mangling in the patch.)
Looks perfect to me, and if people want it, one could add the same option as an
alias to the current --track option to the checkout and branch commands.
> > + /* Chase symbolic refs (mainly for HEAD). */
> > + localname = i->peer_ref->name;
> > + remotename = i->name;
> > + tmp = resolve_ref(localname, sha, 1, &flag);
> > + if (tmp && flag & REF_ISSYMREF &&
> > + !prefixcmp(tmp, "refs/heads/"))
> > + localname = tmp;
I would never have thought of that case - good catch.
> > @@ -974,6 +1016,10 @@ int transport_push(struct transport *transport,
> > verify_remote_names(refspec_nr, refspec);
> >
> > if (transport->push) {
> > + /* Maybe FIXME. But no important transport uses this case. */
> > + if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
> > + die("This transport does not support using --set-upstream");
> > +
That's ONE way to do it - and seriously, I don't know if anyone uses that
transport :P
However, one possible improvement for this case would be setting ALL pushed
refs as tracking if the push succeeded, and none otherwise.
Are new transports going to be added that use transport->push, or is that
interface deprecated anyway?
Best regards,
Rudolf Polzer
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Jeff King @ 2010-01-16 18:28 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Ilari Liusvaara, git
In-Reply-To: <be6fef0d1001160813o674ed93dn33843813be6f45be@mail.gmail.com>
On Sun, Jan 17, 2010 at 12:13:20AM +0800, Tay Ray Chuan wrote:
> On Sat, Jan 16, 2010 at 11:56 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > Hmm... In what conditions ref->status is 'none' after push operation
> > has completed?
>
> when a match between a local and remote ref is not found.
>
> For example, the local ref 'master' will match the remote ref
> 'master', but not 'retsam' ('master' spelled in reverse).
How would it make any sense to set up a tracking branch, then? Not only
is it not desired (if I said "git push -u foo:bar", I don't expect it to
do _anything_ with some other local branch besides foo), but it wouldn't
work, since the peer_ref pointer would be NULL.
-Peff
^ 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