* Re: [PATCHv3 08/13] credential: make relevance of http path configurable
From: Jeff King @ 2011-12-10 19:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3mxb0hcjs.fsf@localhost.localdomain>
On Sat, Dec 10, 2011 at 03:50:11AM -0800, Jakub Narebski wrote:
> > This is nothing you couldn't do with a clever credential
> > helper at the start of your stack, like:
> >
> > [credential "http://"]
> > helper = "!f() { grep -v ^path= ; }; f"
> > helper = your_real_helper
> >
> > But doing this:
> >
> > [credential]
> > useHttpPath = false
>
> Shouldn't this be 'usePath' or 'usePathComponent' or 'useRepositoryPath',
> etc.? Because if^W when remote helper for Subversion is complete, you
> could have svn://svnserve.example.com/path/to/repo as an URL... which
> would be not HTTP(S).
It must be per-protocol, because paths will be relevant for some
protocols (e.g., unlocking certificates in the local filesystem).
So if anything, it would be "useNetworkPath" or something, if we wanted
to unify svn and http. But it would also be OK to have a separate flag
for http and svn, which is more flexible (and most users aren't going to
set it at all, so they won't notice).
-Peff
^ permalink raw reply
* Re: [PATCHv3 11/13] strbuf: add strbuf_add*_urlencode
From: Jeff King @ 2011-12-10 20:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3iplohc6s.fsf@localhost.localdomain>
On Sat, Dec 10, 2011 at 03:57:59AM -0800, Jakub Narebski wrote:
> Jeff King <peff@peff.net> writes:
>
> > +void strbuf_add_urlencode(struct strbuf *sb, const char *s, size_t len,
> > + int reserved)
> > +{
> > + strbuf_grow(sb, len);
>
> What is this `reserved` flag for, and when should one use it?
> It would be nice to have a short comment...
It indicates whether one should encode rfc3986 reserved characters. You
want to use it when encoding the host, username, and password portions
of a URL (i.e., before the "/"), but not the path (since you don't want
to encode all of the slashes). If you were breaking down the path more
(e.g., into a "query" and "fragment" portion), you would care about more
specific quoting there, but we don't; we treat everything after the
slash as an opaque blob of path.
Patch to the strbuf api documentation is below. I think it should be
squashed into patch 12/13.
> BTW. was it meant to be aligned like this?
>
> > +void strbuf_add_urlencode(struct strbuf *sb, const char *s, size_t len,
> > + int reserved)
It is aligned correctly. When you ident by tabs, the "+" of the diff
gets soaked in the first tabstop, so it is off-by-one with respect to
non-tabbed input (it is off even more in the quoted section above,
because "> > +" gets soaked into the first tabstop). You can see your
version above also is misaligned when I quote it. :)
If you apply the diff, the result is as you expected.
-Peff
---
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index afe2759..e1ab6c5 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -270,3 +270,14 @@ same behaviour as well.
third argument can be used to set the environment which the editor is
run in. If the buffer is NULL the editor is launched as usual but the
file's contents are not read into the buffer upon completion.
+
+`strbuf_add_urlencode`::
+
+ Copy data to the end of the buffer, percent-encoding it as per
+ rfc3986. If the reserved flag is non-zero, then characters in
+ the rfc3986 reserved list are percent-encoded; otherwise, they
+ are copied literally. Characters in the rfc3986 unreserved list
+ are always copied literally. All other characters are
+ percent-encoded. Typically, one would use the reserved flag for
+ the host and user-info sections of a URL, but leave special
+ characters in the path untouched.
^ permalink raw reply related
* Re: [PATCH 3/3] Rename resolve_ref() to resolve_ref_unsafe()
From: Jonathan Nieder @ 2011-12-10 20:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <1323521631-24320-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> resolve_ref() may return a pointer to a shared buffer and can be
> overwritten by the next resolve_ref() calls. Callers need to
> pay attention, not to keep the pointer when the next call happens.
[...]
> --- a/branch.c
> +++ b/branch.c
> @@ -182,7 +182,7 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
> const char *head;
> unsigned char sha1[20];
>
> - head = resolve_ref("HEAD", sha1, 0, NULL);
> + head = resolve_ref_unsafe("HEAD", sha1, 0, NULL);
I wonder if it would make sense to have a separate function that
maintains a shared buffer describing what HEAD resolves to, lazily
loaded. Would invalidating the cache when appropriate be too fussy
and subtle?
[...]
> +++ b/transport.c
> @@ -163,7 +163,7 @@ static void set_upstreams(struct transport *transport, struct ref *refs,
> /* Follow symbolic refs (mainly for HEAD). */
> localname = ref->peer_ref->name;
> remotename = ref->name;
> - tmp = resolve_ref(localname, sha, 1, &flag);
> + tmp = resolve_ref_unsafe(localname, sha, 1, &flag);
Anyway, this patch looks sane. The reminder seems useful and doesn't
feel over-the-top.
^ permalink raw reply
* Re: [PATCH 2/3] Guard memory overwriting in resolve_ref's static buffer
From: Jonathan Nieder @ 2011-12-10 21:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <1323521631-24320-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> Michael Haggerty
> has an idea [1] that, instead of passing the same static buffer to
> caller every time the function is called, we free the old buffer and
> allocate the new one. This way access to the old (now invalid) buffer
> may be caught.
>
> This patch applies the same principle for resolve_ref() with a
> few modifications:
[...]
> - Rely on mmap/mprotect to catch illegal access. We need valgrind or
> some other memory tracking tool to reliably catch this in Michael's
> approach.
I wonder if the lower-tech approach would be so bad in practice. On
systems using glibc, if MALLOC_PERTURB_ is set, then the value will
always be clobbered on free(). It would be possible to do the same
explicitly in resolve_ref() for platforms without such a feature.
> - Because mprotect is used instead of munmap, we definitely leak
> memory. Hopefully callers will not put resolve_ref() in a
> loop that runs 1 million times.
Have you measured the performance impact when GIT_DEBUG_MEMCHECK is not
set? (I don't expect major problems, but sometimes code surprises me.)
[...]
> Also introduce a new target, "make memcheck", that runs tests with this
> flag on.
Neat. Did it catch any bugs?
> --- a/cache.h
> +++ b/cache.h
> @@ -865,7 +865,8 @@ extern int read_ref(const char *filename, unsigned char *sha1);
> *
> * errno is sometimes set on errors, but not always.
> */
> -extern const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *flag);
> +#define resolve_ref(ref, sha1, reading, flag) resolve_ref_real(ref, sha1, reading, flag, __FUNCTION__, __LINE__)
__FUNCTION__ is nonstandard, though it's probably supported pretty
widely and we can do
#ifndef __FUNCTION__
#define __FUNCTION__ something-else
#endif
in git-compat-util.h when we discover a platform that doesn't support
it if needed. __func__ was introduced in C99. __LINE__ and __FILE__
should work everywhere.
[...]
> --- /dev/null
> +++ b/t/t0071-memcheck.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +
> +test_description='test that GIT_DEBUG_MEMCHECK works correctly'
> +. ./test-lib.sh
> +
> +test_expect_success 'test-resolve-ref must crash' '
> + GIT_DEBUG_MEMCHECK=1 test-resolve-ref
> + exit_code=$? &&
> + test $exit_code -eq 139
Micronit: something like
(
GIT_DEBUG_MEMCHECK=1 &&
export GIT_DEBUG_MEMCHECK &&
test_expect_code 139 test-resolve-ref
)
would fit better in an &&-list.
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -60,6 +60,28 @@ void *xmallocz(size_t size)
> return ret;
> }
>
> +void *xmalloc_mmap(size_t size, const char *file, int line)
> +{
> + int *ret;
> + size += sizeof(int*) * 3;
> + ret = mmap(NULL, size, PROT_READ | PROT_WRITE,
> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> + if (ret == (int*)-1)
> + die_errno("unable to mmap %lu bytes anonymously",
> + (unsigned long)size);
> +
> + ret[0] = (int)file;
> + ret[1] = line;
> + ret[2] = size;
> + return ret + 3;
Would this work on 64-bit platforms?
How does one retrieve the line and file number? I guess one is
expected to retrieve them from the core dump, but a few words of
advice in Documentation/technical would be helpful.
^ permalink raw reply
* Re: process committed files in post-receive hook
From: Alexey Shumkin @ 2011-12-10 21:31 UTC (permalink / raw)
To: Hao; +Cc: git
In-Reply-To: <loom.20111210T111457-837@post.gmane.org>
> I have two questions. First, is there a way that I can access file
> content in a bare repo without checking out a working copy?
$ git show <commit>:<filename>
e.g. for bare repo of Git the following command
$ git show v1.7.8:Documentation/RelNotes/1.7.8.txt
outputs
--->8---
Git v1.7.8 Release Notes
========================
Updates since v1.7.7
--------------------
* Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates.
* Updates to bash completion scripts.
--->8---
^ permalink raw reply
* Re: Access to git repository through squid proxy: The remote end hung up unexpectedly
From: Konstantin Khomoutov @ 2011-12-10 22:58 UTC (permalink / raw)
To: Mathieu Peltier; +Cc: git
In-Reply-To: <CACjeFCA4h_w2UmYywMBV_P+YZcWAE=zRUz-z5eTfAO+oxWKPjw@mail.gmail.com>
On Sat, Dec 10, 2011 at 09:56:07AM +0100, Mathieu Peltier wrote:
[...]
> 2011/12/09 12:22:44 socat[21428] I setting option "proxyport" to "8080"
> 2011/12/09 12:22:44 socat[21428] I setting option
> "proxy-authorization" to "user:pass"
> ...
> 2011/12/09 12:22:44 socat[21428] I sending "CONNECT
> git.server.org:9418 HTTP/1.0\r\n"
> ...
> 2011/12/09 12:22:44 socat[21428] I proxy_connect: received answer
> "HTTP/1.1 403 OK\r\n"
> 2011/12/09 12:22:44 socat[21428] E CONNECT git.server.org:9418: OK
> 2011/12/09 12:22:44 socat[21428] N exit(1)
> 2011/12/09 12:22:44 socat[21428] I shutdown(3, 2)
> 2011/12/09 12:22:44 socat[21428] D shutdown() -> 0
> fatal: The remote end hung up unexpectedly
[...]
HTTP 403 means "access denied" or "forbidden".
IIRC, a proxy (or any other HTTP-speaking server) should respond with
the 401 code when a client first requests a protected resource, and the
client is then supposed to retry its request but this time it should
provide an authentication info (and the auth mech selected).
You have an ellipsis in your debug output in the place that exchange is
supposed to be happening so I'm unable to dig deeper.
Looks like either your socat supplies incorrect credentials or proxy
does not ask socat to actually authenticate and just denies the request.
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2011-12-11 2:22 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
> Hi,
>
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
I dont think there is a single command to do it for *all*
branches, but for any particular branch, this should work:
git merge --ff-only @{u}
So what you want would boil down to this script (untested):
#!/bin/bash
git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
do
git checkout $b
git merge --ff-only @{u}
done
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Tony Wang @ 2011-12-11 2:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8Bg1=ESaZq8WQmZufsb6E8DY4RHqG0TWG-7uFX671zO6Q@mail.gmail.com>
Just notice that, thanks. :)
--
BR,
Tony Wang
On Saturday, December 10, 2011 at 12:48, Nguyen Thai Ngoc Duy wrote:
> On Sat, Dec 10, 2011 at 10:43 AM, Tony Wang <wwwjfy@gmail.com (mailto:wwwjfy@gmail.com)> wrote:
> > Hi,
> >
> > I don't know about the procedure, but wonder is any one following this?
>
> This series has been merged in master. I'll resend patches to rename
> resolve_ref() to resolve_ref_unsafe() soon.
> --
> Duy
^ permalink raw reply
* Re: git for change control of software deployment updates
From: David Aguilar @ 2011-12-11 3:19 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jbugm2$afc$1@dough.gmane.org>
On Fri, Dec 9, 2011 at 6:37 PM, Neal Kreitzinger <neal@rsss.com> wrote:
> I am considering using git with submodules to deploy most of our updates to
> our customer linux servers (not including third party rpm updates already
> tracked by linux distro rpm repository). Has anyone else done this?
> Comments? (Sanity check.) (I am new to submodules.)
I wrote a script that converts a git source repository into a redhat
src.rpm. We use it at my $dayjob. How about doing something like
that? After you have a src.rpm you can create rpms that you can
distribute using yum. You are already using rpm which is why I
mention it. Converting a directory of rpm files into a hostable
repository is as simple as `createrepo /path/to/rpms/`.
The git project has a 'make rpm' target in its Makefile that you could
use as an example.
--
David
^ permalink raw reply
* Re: git for change control of software deployment updates
From: Neal Kreitzinger @ 2011-12-11 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <CAJDDKr7+GeJTR986DSqKpQRWsXGFVzjBqg6WgRyG-EtycrQs7A@mail.gmail.com>
On 12/10/2011 9:19 PM, David Aguilar wrote:
> On Fri, Dec 9, 2011 at 6:37 PM, Neal Kreitzinger<neal@rsss.com> wrote:
>> I am considering using git with submodules to deploy most of our updates to
>> our customer linux servers (not including third party rpm updates already
>> tracked by linux distro rpm repository). Has anyone else done this?
>> Comments? (Sanity check.) (I am new to submodules.)
>
> I wrote a script that converts a git source repository into a redhat
> src.rpm. We use it at my $dayjob. How about doing something like
> that? After you have a src.rpm you can create rpms that you can
> distribute using yum. You are already using rpm which is why I
> mention it. Converting a directory of rpm files into a hostable
> repository is as simple as `createrepo /path/to/rpms/`.
>
> The git project has a 'make rpm' target in its Makefile that you could
> use as an example.
We use rhel so, yes, we use the redhat repo to get rhel patches. Is
that what you mean by "You are already using rpm"? (We do not write our
own rpm's at this time.)
v/r,
neal
^ permalink raw reply
* Re: [PATCH 2/3] Guard memory overwriting in resolve_ref's static buffer
From: Nguyen Thai Ngoc Duy @ 2011-12-11 9:22 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <20111210211040.GB24817@elie.hsd1.il.comcast.net>
2011/12/11 Jonathan Nieder <jrnieder@gmail.com>:
>> - Rely on mmap/mprotect to catch illegal access. We need valgrind or
>> some other memory tracking tool to reliably catch this in Michael's
>> approach.
>
> I wonder if the lower-tech approach would be so bad in practice. On
> systems using glibc, if MALLOC_PERTURB_ is set, then the value will
> always be clobbered on free(). It would be possible to do the same
> explicitly in resolve_ref() for platforms without such a feature.
Clobbered value may be carried around for some time before the code
detects wrong value. It'd be hard to track back where the root cause
is.
>> - Because mprotect is used instead of munmap, we definitely leak
>> memory. Hopefully callers will not put resolve_ref() in a
>> loop that runs 1 million times.
>
> Have you measured the performance impact when GIT_DEBUG_MEMCHECK is not
> set? (I don't expect major problems, but sometimes code surprises me.)
No. I wish we had a performance test suite. Which use cases should I test?
> [...]
>> Also introduce a new target, "make memcheck", that runs tests with this
>> flag on.
>
> Neat. Did it catch any bugs?
No, otherwise I would have sent more patches ;)
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -865,7 +865,8 @@ extern int read_ref(const char *filename, unsigned char *sha1);
>> *
>> * errno is sometimes set on errors, but not always.
>> */
>> -extern const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *flag);
>> +#define resolve_ref(ref, sha1, reading, flag) resolve_ref_real(ref, sha1, reading, flag, __FUNCTION__, __LINE__)
>
> __FUNCTION__ is nonstandard, though it's probably supported pretty
> widely and we can do
>
> #ifndef __FUNCTION__
> #define __FUNCTION__ something-else
> #endif
>
> in git-compat-util.h when we discover a platform that doesn't support
> it if needed. __func__ was introduced in C99. __LINE__ and __FILE__
> should work everywhere.
Will change to __FILE__ then
>> --- a/wrapper.c
>> +++ b/wrapper.c
>> @@ -60,6 +60,28 @@ void *xmallocz(size_t size)
>> return ret;
>> }
>>
>> +void *xmalloc_mmap(size_t size, const char *file, int line)
>> +{
>> + int *ret;
>> + size += sizeof(int*) * 3;
>> + ret = mmap(NULL, size, PROT_READ | PROT_WRITE,
>> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>> + if (ret == (int*)-1)
>> + die_errno("unable to mmap %lu bytes anonymously",
>> + (unsigned long)size);
>> +
>> + ret[0] = (int)file;
>> + ret[1] = line;
>> + ret[2] = size;
>> + return ret + 3;
>
> Would this work on 64-bit platforms?
No idea (I'm on 32-bit). I don't see any reasons why it would not
work. But that function may cause unaligned access, I think.
> How does one retrieve the line and file number? I guess one is
> expected to retrieve them from the core dump, but a few words of
> advice in Documentation/technical would be helpful.
from coredump.
--
Duy
^ permalink raw reply
* Re: [PATCH 3/3] Rename resolve_ref() to resolve_ref_unsafe()
From: Nguyen Thai Ngoc Duy @ 2011-12-11 9:46 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <20111210205519.GA24817@elie.hsd1.il.comcast.net>
2011/12/11 Jonathan Nieder <jrnieder@gmail.com>:
> Nguyễn Thái Ngọc Duy wrote:
>
>> resolve_ref() may return a pointer to a shared buffer and can be
>> overwritten by the next resolve_ref() calls. Callers need to
>> pay attention, not to keep the pointer when the next call happens.
> [...]
>> --- a/branch.c
>> +++ b/branch.c
>> @@ -182,7 +182,7 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
>> const char *head;
>> unsigned char sha1[20];
>>
>> - head = resolve_ref("HEAD", sha1, 0, NULL);
>> + head = resolve_ref_unsafe("HEAD", sha1, 0, NULL);
>
> I wonder if it would make sense to have a separate function that
> maintains a shared buffer describing what HEAD resolves to, lazily
> loaded. Would invalidating the cache when appropriate be too fussy
> and subtle?
If we do not execute "git update-ref" from git binary (bisect does,
although on BISECT_HEAD, not HEAD) then it'd be safe to cache HEAD and
invalidate it in update_ref().
--
Duy
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Phil Hord @ 2011-12-11 14:43 UTC (permalink / raw)
To: Andreas T.Auer; +Cc: Jens Lehmann, git
In-Reply-To: <4EE2B8C3.6000906@ursus.ath.cx>
On Fri, Dec 9, 2011 at 8:41 PM, Andreas T.Auer
<andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>>> It is even nice to see which commits in the submodule belong to what
>>> branches in the superproject or to what release version (so tracking
>>> superproject tags would make sense, too). If you have a submodule that
>>> has
>>> more than one superproject but these are well-defined, it could be solved
>>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for
>>> the
>>> other superproject), but currently I can't think of a context where this
>>> makes sense.
>>
>> I can, but this does put the cart before the horse. The submodule is
>> subservient to the super project in all my setups. The submodule is
>> not aware who owns him. He is a bit like the DAG in reverse. He
>> knows one direction only (children), not the other (parents).
>
> In the setup I have in mind, the submodules are not subservient to the
> superproject, but a part of the whole project.
I see that. I have a similar project with about 20 submodules. None
of them are useful on their own; they are logical divisions of a large
project.
Architecturally, submodules are oblivious of their super-projects in
all other respects. Changing the architectural underpinnings should
be a last resort, I think.
Phil
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <20111211022218.GA22749@sita-lt.atc.tcs.com>
On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
> On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
>> Hi,
>>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> I dont think there is a single command to do it for *all*
> branches, but for any particular branch, this should work:
A tiny script is fine. I didn't really expect the magic command.
Currently I'm using one script per repository, which hard coded the
branches,
that I want to fast-forward (checking them out and doing a git-pull)
>
> git merge --ff-only @{u}
>
Thanks, '--ff=only @{u}' is already the first improvement for my script.
> So what you want would boil down to this script (untested):
>
> #!/bin/bash
> git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
>
> for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
> do
> git checkout $b
> git merge --ff-only @{u}
> done
Is there no way to distinguish tracking branches from other branches?
without checking them out?
In order to save time I'd like to avoid checking out local branches.
Ideally I would even like to avoid checking out branches, which don't
need to be forwarded.
I also had to remember on which branch I was in order to avoid, that I
am at a random branch after running the script.
I could imagine something like my snippet below , though I guess,
there's something more elegant.
git stash
mybranch=`git branch | sed -n 's/\* *//p'`
# do_script . . .
git checkout $mybranch
git stash apply
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Martin Langhoff @ 2011-12-11 16:27 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
On Sat, Dec 10, 2011 at 7:26 AM, Gelonida N <gelonida@gmail.com> wrote:
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
It'd be a great addition to git fetch ;-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Jakub Narebski @ 2011-12-11 18:22 UTC (permalink / raw)
To: Gelonida N; +Cc: git, Sitaram Chamarty
In-Reply-To: <jc2l2a$som$1@dough.gmane.org>
Don't remove people from Cc, please.
Gelonida N <gelonida@gmail.com> writes:
> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
> > On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
> > So what you want would boil down to this script (untested):
> >
> > #!/bin/bash
> > git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
> >
> > for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
> > do
> > git checkout $b
> > git merge --ff-only @{u}
> > done
>
> Is there no way to distinguish tracking branches from other branches?
> without checking them out?
>
> In order to save time I'd like to avoid checking out local branches.
You can use 'upstream' field name in git-for-each-ref invocation,
for example
git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
grep -e ' [^ ]' |
sed -e 's/ .*$//
This could probably be done using only sed -- grep is not necessary.
> Ideally I would even like to avoid checking out branches, which don't
> need to be forwarded.
You can use git-update-ref plumbing, but you would have to do the
check if it does fast-forward yourself, and provide reflog message
yourself too.
Something like
git for-each-ref '--format=%(refname) %(upstream)' |
while read refname upstream
do
# there is upstream
test -n "$upstream" || break
# and if fast-forwards
test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
git update-ref -m "$message" $refname $upstream
done
> I also had to remember on which branch I was in order to avoid, that I
> am at a random branch after running the script.
>
> I could imagine something like my snippet below , though I guess,
> there's something more elegant.
>
> git stash
> mybranch=`git branch | sed -n 's/\* *//p'`
> # do_script . . .
> git checkout $mybranch
> git stash apply
Don't use git-branch in scripting. See __git_ps1 function in
contrib/completion/git-completion.bash how it can be done:
b="$(git symbolic-ref HEAD 2>/dev/null)" ||
b="$(git rev-parse --verify HEAD)"
Nb. the second part is here only if there is possibility that you are
on detached HEAD (unnamed branch).
HTH (hope that helps)
--
Jakub Narębski
^ permalink raw reply
* Breakage (?) in configure and git_vsnprintf()
From: Michael Haggerty @ 2011-12-11 18:42 UTC (permalink / raw)
To: git discussion list; +Cc: Michal Rokos, Brandon Casey
I found a mysterious bunch of test suite failures when I compiled git on
a 64-bit Linux 3.0.0 using gcc 4.6.1:
git clean -f -x -d
make clean
make configure
./configure --prefix=$HOME CFLAGS='-g -O0 -std=c89 -Wall -Werror'
make test
The failure unexpectedly depended on the presence of all three compiler
options "-std=c89 -Wall -Werror". There is no difference between -O0
and -O2. The breakage is in v1.7.7, v1.7.8, and master (I didn't try
older versions).
I have been using "-std=c89" when compiling to avoid accidentally using
newer C features. Perhaps that is unwise :-)
The same test succeeds on 32-bit Linux 2.6.32 using gcc 4.4.3.
There seem to be two levels to the problem:
1. With this choice of compiler options, configure incorrectly convinces
itself that the system's snprintf() is broken and sets
SNPRINTF_RETURNS_BOGUS. From config.log:
configure:5368: checking whether snprintf() and/or vsnprintf() return
bogus value
configure:5406: cc -o conftest -g -O0 --std=c89 -Wall -Werror
conftest.c >&5
conftest.c: In function 'test_vsnprintf':
conftest.c:62:5: error: implicit declaration of function 'vsnprintf'
[-Werror=implicit-function-declaration]
conftest.c: In function 'main':
conftest.c:72:5: error: implicit declaration of function 'snprintf'
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
configure:5406: $? = 1
configure: program exited with status 1
According to the manpage, snprintf() and vsnprintf() are truly not
supported for "-std=c89" and indeed they are not declared by any of the
files included by the test program that configure is using. (Oddly,
although they are nominally not supported, vsnprintf() is used anyway in
the definition of git_vsnprintf().)
If I leave off any of the compilation options "-std=c89 -Wall -Werror"
or if I toggle the "#ifdef SNPRINTF_RETURNS_BOGUS" line in
git-compat-util.h off, the problem goes away.
2. The configure problem causes git_vsnprintf() to be wrapped around the
C library version. This leads to many failures in the test suite. I
suppose that git_vsnprintf() is broken in some way.
I'm kindof busy with my ref-api patch series so I won't have time to
look further into this problem in the near future. But perhaps somebody
with experience with the configuration system and/or git_vsnprintf() is
interested.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2011-12-11 18:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Gelonida N, git
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
2011/12/11 Jakub Narebski <jnareb@gmail.com>:
> Don't remove people from Cc, please.
>
> Gelonida N <gelonida@gmail.com> writes:
>> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
>> > On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
>
>> > So what you want would boil down to this script (untested):
>> >
>> > #!/bin/bash
>> > git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
>> >
>> > for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
>> > do
>> > git checkout $b
>> > git merge --ff-only @{u}
>> > done
>>
>> Is there no way to distinguish tracking branches from other branches?
>> without checking them out?
>>
>> In order to save time I'd like to avoid checking out local branches.
>
> You can use 'upstream' field name in git-for-each-ref invocation,
> for example
>
> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
> grep -e ' [^ ]' |
> sed -e 's/ .*$//
>
> This could probably be done using only sed -- grep is not necessary.
>
>> Ideally I would even like to avoid checking out branches, which don't
>> need to be forwarded.
>
> You can use git-update-ref plumbing, but you would have to do the
> check if it does fast-forward yourself, and provide reflog message
> yourself too.
if it's not the currently checked-out branch, 'git branch -f foo
origin/foo' seems to work fine. However, it only updates the branch
reflog, not the HEAD reflog also, naturally.
FWIW...
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
>
>> I also had to remember on which branch I was in order to avoid, that I
>> am at a random branch after running the script.
>>
>> I could imagine something like my snippet below , though I guess,
>> there's something more elegant.
>>
>> git stash
>> mybranch=`git branch | sed -n 's/\* *//p'`
>> # do_script . . .
>> git checkout $mybranch
>> git stash apply
>
> Don't use git-branch in scripting. See __git_ps1 function in
> contrib/completion/git-completion.bash how it can be done:
>
> b="$(git symbolic-ref HEAD 2>/dev/null)" ||
> b="$(git rev-parse --verify HEAD)"
>
> Nb. the second part is here only if there is possibility that you are
> on detached HEAD (unnamed branch).
>
> HTH (hope that helps)
> --
> Jakub Narębski
--
Sitaram
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Andreas Schwab @ 2011-12-11 19:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Gelonida N, git, Sitaram Chamarty
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
You probably meant s/break/continue/.
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: best way to fastforward all tracking branches after a fetch
From: Jakub Narebski @ 2011-12-11 19:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Gelonida N, git, Sitaram Chamarty
In-Reply-To: <m2hb176iiy.fsf@igel.home>
Andreas Schwab wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Something like
> >
> > git for-each-ref '--format=%(refname) %(upstream)' |
> > while read refname upstream
> > do
> > # there is upstream
> > test -n "$upstream" || break
Here you should probably also check if we are already up-to-date:
test $(git rev-parse $upstream) = $(git rev-parse $refname) || continue
> > # and if fast-forwards
> > test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> > git update-ref -m "$message" $refname $upstream
> > done
>
> You probably meant s/break/continue/.
Yes, sorry about that.
BTW. git-update-ref invocation can be replaced by Sitaram's suggestion:
git branch -f $refname $upstream
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 19:58 UTC (permalink / raw)
To: git; +Cc: Sitaram Chamarty
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
On 12/11/2011 07:22 PM, Jakub Narebski wrote:
> Don't remove people from Cc, please.
OK,
>
> Gelonida N <gelonida@gmail.com> writes:
>> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
>>
>> In order to save time I'd like to avoid checking out local branches.
>
> You can use 'upstream' field name in git-for-each-ref invocation,
> for example
>
> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
> grep -e ' [^ ]' |
> sed -e 's/ .*$//
>
Thanks
> This could probably be done using only sed -- grep is not necessary.
I think the equivalent would be:
sed '/ [^ ]/ s/ .*$//'
>
>> Ideally I would even like to avoid checking out branches, which don't
>> need to be forwarded.
>
> You can use git-update-ref plumbing, but you would have to do the
> check if it does fast-forward yourself, and provide reflog message
> yourself too.
>
True this would probably be fastest. Will read the docs a little to
understand exactly what you're doing. I'm not that much used to all the
commands used in the script.
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
>
>> I also had to remember on which branch I was in order to avoid, that I
>> am at a random branch after running the script.
>>
>
> Don't use git-branch in scripting. See __git_ps1 function in
> contrib/completion/git-completion.bash how it can be done:
>
> b="$(git symbolic-ref HEAD 2>/dev/null)" ||
> b="$(git rev-parse --verify HEAD)"
>
> Nb. the second part is here only if there is possibility that you are
> on detached HEAD (unnamed branch).
>
> HTH (hope that helps)
It definitely helps. Thanks a lot.
It's always good to see how one can do better after some attempts o some
self made clumsy scripts not suing all the features of git.
^ permalink raw reply
* Re: [RFC/PATCH 0/7] some sequencer loose ends (Re: Fix revert --abort on Windows)
From: Jonathan Nieder @ 2011-12-11 19:58 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Jay Soffian
In-Reply-To: <20111210124644.GA22035@elie.hsd1.il.comcast.net>
Jonathan Nieder wrote:
> Here are patches to address some UI warts
[... rambling cover letter snipped ...]
Let's try that again. :)
Current git has a somewhat odd behavior when cherry-picking multiple
commits and running into a conflict in the _last_ commit of the
series. Imagine the following sequence of operations:
1. git cherry-pick simplething simplethingtwo complexthing
2. CONFLICT.
3. git cherry-pick --abort
It would be most consistent for the entire cherry-pick sequence to be
rolled back, so the user can come up with some other sequence of
commits to try. After all, that's what happens if a conflict is
encountered applying simplethingtwo and the user asks to abort.
Instead, by the time complexthing is being applied, git has forgotten
about the multi-pick sequence entirely. And the --abort does not even
warn about this weird state --- it just cancels complexthing and
leaves the earlier commits applied.
This is an edge case, but I think it's worth fixing. Patch 5/7 does
so.
In the same vein, now imagine a different sequence of operations:
1. git cherry-pick simplething complexthing morecommits...
2. CONFLICT.
3. git reset --merge
4. git cherry-pick --continue
It would be sensible for this to remove the conflicted patch and go
on with the remaining ones, right? But instead, "git reset"
automagically removes the sequencer state, so you can't even use
git cherry-pick --abort any more. Well, you can, if you say the
magic words "mv .git/sequencer-old .git/sequencer", but nobody
actually tells you that.
How did we ever let this in? "git reset" already has well defined
semantics that have nothing to do with this. Patches 6/7 and 7/7
would help us forget this UI mistake (and I believe it was a mistake)
ever happened.
Patch 2 makes cherry-pick --continue behave a little more like
rebase --continue, for people who like to learn by analogy.
Patches 1 and 3 are just code style things.
Patch 4 is the basic building block that makes patch 5 possible: it
teaches "git cherry-pick" to treat picks of a single commit named on
the command line differently from the more complex multi-picks
requested with general rev-list arguments. Single-pick is all that
git cherry-pick originally supported, and in some details it has to
differ from multi-pick (for example, "git commit" after resolving
conflicts after a conflicted single-pick needs to be enough to clear
the state). As a side-benefit, we get the ability to do a single-pick
in the middle of a multi-pick, which is kind of cool and handy from
time to time.
I am interested in sanity checking of the patches and testing. It
would be pleasant to find comments like "yeah, that looks good" or
"what are you thinking?! I ran into the following bug" arriving in my
inbox.
Incidentally, I'd like to apologize about not protesting more about
these things (and even having suggested some of them) as they
happened. Instead of exercising careful oversight over the sanity of
patches that passed through my mailbox, I had some strange idea of
using the Socratic method to help others learn to explore the design
space and sanity-check findings themselves...
Thanks for reading.
Ciao,
Jonathan
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Stefan Haller @ 2011-12-11 20:14 UTC (permalink / raw)
To: Gelonida N, git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
Gelonida N <gelonida@gmail.com> wrote:
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
Here's a script that does this. It isn't very well tested, I hope I
didn't miss any edge cases. Use at your own risk.
(It doesn't fastforward the branch you're on, on the assumtion that if
you said git fetch instead of git pull, you probably had a reason.)
========= 8< =========
#!/bin/sh
currentbranch="`git symbolic-ref HEAD 2>/dev/null`"
git for-each-ref --shell --format='ref=%(refname);upstream=%(upstream)' \
refs/heads | \
while read entry
do
eval "$entry"
# skip the current branch
test "$ref" = "$currentbranch" && continue
# skip branches that have no upstream
test -z "$upstream" && continue
# skip if upstream doesn't have any new commits
if [ -z "`git rev-list "$ref..$upstream"`" ]; then
echo "${ref#refs/heads/} is up to date"
continue
fi
# error if there are local commits
if [ -n "`git rev-list "$upstream..$ref"`" ]; then
echo "${ref#refs/heads/} has local commits; can't fast-forward"
continue
fi
echo "${ref#refs/heads/} -> ${upstream#refs/remotes/}"
git update-ref -m ff-all-branches "$ref" "$upstream"
done
========= >8 =========
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <1kc4qnw.1xgi3yf14oaw7gM%lists@haller-berlin.de>
On 12/11/2011 09:14 PM, Stefan Haller wrote:
> Gelonida N <gelonida@gmail.com> wrote:
>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> Here's a script that does this. It isn't very well tested, I hope I
> didn't miss any edge cases. Use at your own risk.
>
> (It doesn't fastforward the branch you're on, on the assumtion that if
> you said git fetch instead of git pull, you probably had a reason.)
Agreed. it might be reasonable to ignore the current branch if it wasn't
pulled.
Thanks a lot for the script. I will play with it.
>
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Andreas Schwab @ 2011-12-11 20:30 UTC (permalink / raw)
To: Gelonida N; +Cc: git, Sitaram Chamarty
In-Reply-To: <4EE50B5A.3000706@gmail.com>
Gelonida N <gelonida@gmail.com> writes:
> On 12/11/2011 07:22 PM, Jakub Narebski wrote:
>> You can use 'upstream' field name in git-for-each-ref invocation,
>> for example
>>
>> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
>> grep -e ' [^ ]' |
>> sed -e 's/ .*$//
>>
> Thanks
>
>
>
>> This could probably be done using only sed -- grep is not necessary.
> I think the equivalent would be:
> sed '/ [^ ]/ s/ .*$//'
You need to suppress printing the non-matching lines.
sed -n '/ [^ ]/ s/ .*$//p'
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
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