* Re: Usability of git stash
From: Anders Melchiorsen @ 2008-10-18 9:26 UTC (permalink / raw)
To: Brandon Casey; +Cc: David Kastrup, git
In-Reply-To: <vCcONcOJu3QKQyRgPdT5Dws3F2P25RNAFOgM5GX6FWWKJe40papCRw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> In exchange for allowing new users to stub their toe on new commands, the
> work flow of more experienced users is made a little easier.
I wonder whether experienced users even use stash a lot. Personally,
after getting my head around the DAG, and thus getting more
comfortable with git reset, I tend to make "WIP" commits instead.
After having used "git stash clear" at a bad time once, I am wary of
stashing work that I actually want to keep. I prefer workflows where
my mistakes can be (easily) corrected.
The primary thing that stash does for me is preserve the index state.
Unfortunately, --index is not default for stash apply, so I often
forget it.
Sometimes, I also want stash to store away changes to untracked files
(to get a clean working directory), but that is not possible.
Maybe I just don't quite understand what git stash is about ...
Anders.
^ permalink raw reply
* [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Anders Melchiorsen @ 2008-10-18 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzll2epuh.fsf@gitster.siamese.dyndns.org>
With the previous text, one could get the understanding that
diff-filter=T also tested for changes in the executable bit.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Junio C Hamano <gitster@pobox.com> writes:
> There are other "commit pickers" such as -S<strting> and
> --diff-filter that do not absolutely have to exist (iow, they could
> also be scripted), but what they pick earned easy shortcuts because
> the need is very common. Once you can demonstrate that the need to
> pick executable-bit changes is also very common, _and_ if you can
> come up with a clean solution, we might add a commit picker that
> looks for changes in executable-ness in the future. I dunno.
You are right that this should be a rare need.
I didn't mean to push for this feature. I just offered to implement
it, as I needed it myself and din't see other ways. A script will work
fine for me, I should have thought of that.
The documentation patch that I promised is here.
Thanks,
Anders.
Documentation/diff-options.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 7788d4f..7604a13 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -137,7 +137,7 @@ endif::git-format-patch[]
--diff-filter=[ACDMRTUXB*]::
Select only files that are Added (`A`), Copied (`C`),
Deleted (`D`), Modified (`M`), Renamed (`R`), have their
- type (mode) changed (`T`), are Unmerged (`U`), are
+ type (symlink/regular file) changed (`T`), are Unmerged (`U`), are
Unknown (`X`), or have had their pairing Broken (`B`).
Any combination of the filter characters may be used.
When `*` (All-or-none) is added to the combination, all
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Re: StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Catalin Marinas @ 2008-10-18 8:48 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200810152025.19995.arvidjaar@mail.ru>
2008/10/15 Andrey Borzenkov <arvidjaar@mail.ru>:
> Funny problem. I have following export template:
>
> Subject: [PATCH] %(shortdescr)s
> From: %(authname)s %(authemail)s
>
> %(longdescr)s
> Signed-off-by: %(authname)s %(authemail)s
The default templates contain "%(authname)s <%(authemail)s>", i.e.
with the angle brackets arount authemail and I've never seen this
problem. Does it work if you change them (or use the default
templates)?
--
Catalin
^ permalink raw reply
* [PATCH 3/3] make alloc_ref_from_str() the new alloc_ref()
From: René Scharfe @ 2008-10-18 8:44 UTC (permalink / raw)
Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <48F9A13D.3090401@lsrfire.ath.cx>
With all calls to alloc_ref() gone, we can remove it and then we're free
to give alloc_ref_from_str() the shorter name. It's a much nicer
interface, as the callers always need to have a name string when they
allocate a ref anyway and don't need to calculate and pass its length+1
any more.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-fetch.c | 4 ++--
connect.c | 2 +-
http-push.c | 4 ++--
remote.c | 21 +++++++--------------
remote.h | 4 +---
transport.c | 8 ++++----
walker.c | 2 +-
7 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..e008ee9 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -521,8 +521,8 @@ static void find_non_local_tags(struct transport *transport,
will_fetch(head, ref->old_sha1))) {
string_list_insert(ref_name, &new_refs);
- rm = alloc_ref_from_str(ref_name);
- rm->peer_ref = alloc_ref_from_str(ref_name);
+ rm = alloc_ref(ref_name);
+ rm->peer_ref = alloc_ref(ref_name);
hashcpy(rm->old_sha1, ref_sha1);
**tail = rm;
diff --git a/connect.c b/connect.c
index b69060b..0c50d0a 100644
--- a/connect.c
+++ b/connect.c
@@ -90,7 +90,7 @@ struct ref **get_remote_heads(int in, struct ref **list,
continue;
if (nr_match && !path_match(name, nr_match, match))
continue;
- ref = alloc_ref_from_str(buffer + 41);
+ ref = alloc_ref(buffer + 41);
hashcpy(ref->old_sha1, old_sha1);
*list = ref;
list = &ref->next;
diff --git a/http-push.c b/http-push.c
index 42f4d78..5cecef4 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1780,7 +1780,7 @@ static void one_remote_ref(char *refname)
struct ref *ref;
struct object *obj;
- ref = alloc_ref_from_str(refname);
+ ref = alloc_ref(refname);
if (http_fetch_ref(remote->url, ref) != 0) {
fprintf(stderr,
@@ -1887,7 +1887,7 @@ static void add_remote_info_ref(struct remote_ls_ctx *ls)
char *ref_info;
struct ref *ref;
- ref = alloc_ref_from_str(ls->dentry_name);
+ ref = alloc_ref(ls->dentry_name);
if (http_fetch_ref(remote->url, ref) != 0) {
fprintf(stderr,
diff --git a/remote.c b/remote.c
index 44d681d..e530a21 100644
--- a/remote.c
+++ b/remote.c
@@ -759,15 +759,9 @@ static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
return ref;
}
-struct ref *alloc_ref(unsigned namelen)
+struct ref *alloc_ref(const char *name)
{
- struct ref *ret = xcalloc(1, sizeof(struct ref) + namelen);
- return ret;
-}
-
-struct ref *alloc_ref_from_str(const char* str)
-{
- return alloc_ref_with_prefix("", 0, str);
+ return alloc_ref_with_prefix("", 0, name);
}
static struct ref *copy_ref(const struct ref *ref)
@@ -878,20 +872,20 @@ static struct ref *try_explicit_object_name(const char *name)
struct ref *ref;
if (!*name) {
- ref = alloc_ref_from_str("(delete)");
+ ref = alloc_ref("(delete)");
hashclr(ref->new_sha1);
return ref;
}
if (get_sha1(name, sha1))
return NULL;
- ref = alloc_ref_from_str(name);
+ ref = alloc_ref(name);
hashcpy(ref->new_sha1, sha1);
return ref;
}
static struct ref *make_linked_ref(const char *name, struct ref ***tail)
{
- struct ref *ret = alloc_ref_from_str(name);
+ struct ref *ret = alloc_ref(name);
tail_link_ref(ret, tail);
return ret;
}
@@ -1196,9 +1190,8 @@ static struct ref *get_local_ref(const char *name)
if (!name)
return NULL;
- if (!prefixcmp(name, "refs/")) {
- return alloc_ref_from_str(name);
- }
+ if (!prefixcmp(name, "refs/"))
+ return alloc_ref(name);
if (!prefixcmp(name, "heads/") ||
!prefixcmp(name, "tags/") ||
diff --git a/remote.h b/remote.h
index c6163ff..d2e170c 100644
--- a/remote.h
+++ b/remote.h
@@ -55,9 +55,7 @@ struct refspec {
extern const struct refspec *tag_refspec;
-struct ref *alloc_ref(unsigned namelen);
-
-struct ref *alloc_ref_from_str(const char* str);
+struct ref *alloc_ref(const char *name);
struct ref *copy_ref_list(const struct ref *ref);
diff --git a/transport.c b/transport.c
index 3d03475..cfb7350 100644
--- a/transport.c
+++ b/transport.c
@@ -75,7 +75,7 @@ static int read_loose_refs(struct strbuf *path, int name_offset,
if (fd < 0)
continue;
- next = alloc_ref_from_str(path->buf + name_offset);
+ next = alloc_ref(path->buf + name_offset);
if (read_in_full(fd, buffer, 40) != 40 ||
get_sha1_hex(buffer, next->old_sha1)) {
close(fd);
@@ -126,7 +126,7 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
(*list)->next->name)) > 0)
list = &(*list)->next;
if (!(*list)->next || cmp < 0) {
- struct ref *next = alloc_ref_from_str(buffer + 41);
+ struct ref *next = alloc_ref(buffer + 41);
buffer[40] = '\0';
if (get_sha1_hex(buffer, next->old_sha1)) {
warning ("invalid SHA-1: %s", buffer);
@@ -499,7 +499,7 @@ static struct ref *get_refs_via_curl(struct transport *transport)
strbuf_release(&buffer);
- ref = alloc_ref_from_str("HEAD");
+ ref = alloc_ref("HEAD");
if (!walker->fetch_ref(walker, ref) &&
!resolve_remote_symref(ref, refs)) {
ref->next = refs;
@@ -540,7 +540,7 @@ static struct ref *get_refs_from_bundle(struct transport *transport)
die ("Could not read bundle '%s'.", transport->url);
for (i = 0; i < data->header.references.nr; i++) {
struct ref_list_entry *e = data->header.references.list + i;
- struct ref *ref = alloc_ref_from_str(e->name);
+ struct ref *ref = alloc_ref(e->name);
hashcpy(ref->old_sha1, e->sha1);
ref->next = result;
result = ref;
diff --git a/walker.c b/walker.c
index 6b4cf70..679adab 100644
--- a/walker.c
+++ b/walker.c
@@ -191,7 +191,7 @@ static int interpret_target(struct walker *walker, char *target, unsigned char *
if (!get_sha1_hex(target, sha1))
return 0;
if (!check_ref_format(target)) {
- struct ref *ref = alloc_ref_from_str(target);
+ struct ref *ref = alloc_ref(target);
if (!walker->fetch_ref(walker, ref)) {
hashcpy(sha1, ref->old_sha1);
free(ref);
--
1.6.0.2.542.gde55
^ permalink raw reply related
* [PATCH 2/3] use alloc_ref_from_str() everywhere
From: René Scharfe @ 2008-10-18 8:41 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <48F9A054.4010703@lsrfire.ath.cx>
Replace pairs of alloc_ref() and strcpy() with alloc_ref_from_str(),
simplifying the code.
In connect.c, also a pair of alloc_ref() and memcpy() is replaced --
the additional cost of a strlen() call should not have too much of an
impact. Consistency and simplicity are more important.
In remote.c, the code was allocating 11 bytes more than needed for
the name part, but I couldn't see them being used for anything.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
connect.c | 3 +--
remote.c | 3 +--
transport.c | 6 ++----
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/connect.c b/connect.c
index 67d2cd8..b69060b 100644
--- a/connect.c
+++ b/connect.c
@@ -90,9 +90,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
continue;
if (nr_match && !path_match(name, nr_match, match))
continue;
- ref = alloc_ref(name_len + 1);
+ ref = alloc_ref_from_str(buffer + 41);
hashcpy(ref->old_sha1, old_sha1);
- memcpy(ref->name, buffer + 41, name_len + 1);
*list = ref;
list = &ref->next;
}
diff --git a/remote.c b/remote.c
index 98cbcf9..44d681d 100644
--- a/remote.c
+++ b/remote.c
@@ -878,8 +878,7 @@ static struct ref *try_explicit_object_name(const char *name)
struct ref *ref;
if (!*name) {
- ref = alloc_ref(20);
- strcpy(ref->name, "(delete)");
+ ref = alloc_ref_from_str("(delete)");
hashclr(ref->new_sha1);
return ref;
}
diff --git a/transport.c b/transport.c
index 5110c56..3d03475 100644
--- a/transport.c
+++ b/transport.c
@@ -75,15 +75,14 @@ static int read_loose_refs(struct strbuf *path, int name_offset,
if (fd < 0)
continue;
- next = alloc_ref(path->len - name_offset + 1);
+ next = alloc_ref_from_str(path->buf + name_offset);
if (read_in_full(fd, buffer, 40) != 40 ||
get_sha1_hex(buffer, next->old_sha1)) {
close(fd);
free(next);
continue;
}
close(fd);
- strcpy(next->name, path->buf + name_offset);
(*tail)->next = next;
*tail = next;
}
@@ -127,14 +126,13 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
(*list)->next->name)) > 0)
list = &(*list)->next;
if (!(*list)->next || cmp < 0) {
- struct ref *next = alloc_ref(len - 40);
+ struct ref *next = alloc_ref_from_str(buffer + 41);
buffer[40] = '\0';
if (get_sha1_hex(buffer, next->old_sha1)) {
warning ("invalid SHA-1: %s", buffer);
free(next);
continue;
}
- strcpy(next->name, buffer + 41);
next->next = (*list)->next;
(*list)->next = next;
list = &(*list)->next;
--
1.6.0.2.542.gde55
^ permalink raw reply related
* [PATCH 1/3] add alloc_ref_with_prefix()
From: René Scharfe @ 2008-10-18 8:37 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In three cases in remote.c, a "raw" ref is allocated using alloc_ref()
and then its is constructed using sprintf(). Clean it up by adding a
helper function, alloc_ref_with_prefix(), which creates a composite
name. Use it in alloc_ref_from_str(), too, as it simplifies the code.
Open code alloc_ref() in alloc_ref_with_prefix(), as the former is
going to be removed in the patch after the next.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
remote.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/remote.c b/remote.c
index 8a04066..98cbcf9 100644
--- a/remote.c
+++ b/remote.c
@@ -749,6 +749,16 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
return -1;
}
+static struct ref *alloc_ref_with_prefix(const char *prefix, size_t prefixlen,
+ const char *name)
+{
+ size_t len = strlen(name);
+ struct ref *ref = xcalloc(1, sizeof(struct ref) + prefixlen + len + 1);
+ memcpy(ref->name, prefix, prefixlen);
+ memcpy(ref->name + prefixlen, name, len);
+ return ref;
+}
+
struct ref *alloc_ref(unsigned namelen)
{
struct ref *ret = xcalloc(1, sizeof(struct ref) + namelen);
@@ -757,9 +767,7 @@ struct ref *alloc_ref(unsigned namelen)
struct ref *alloc_ref_from_str(const char* str)
{
- struct ref *ret = alloc_ref(strlen(str) + 1);
- strcpy(ret->name, str);
- return ret;
+ return alloc_ref_with_prefix("", 0, str);
}
static struct ref *copy_ref(const struct ref *ref)
@@ -1152,10 +1160,8 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
struct ref *cpy = copy_ref(ref);
match = ref->name + remote_prefix_len;
- cpy->peer_ref = alloc_ref(local_prefix_len +
- strlen(match) + 1);
- sprintf(cpy->peer_ref->name, "%s%s",
- refspec->dst, match);
+ cpy->peer_ref = alloc_ref_with_prefix(refspec->dst,
+ local_prefix_len, match);
if (refspec->force)
cpy->peer_ref->force = 1;
*tail = cpy;
@@ -1188,7 +1194,6 @@ struct ref *get_remote_ref(const struct ref *remote_refs, const char *name)
static struct ref *get_local_ref(const char *name)
{
- struct ref *ret;
if (!name)
return NULL;
@@ -1198,15 +1203,10 @@ static struct ref *get_local_ref(const char *name)
if (!prefixcmp(name, "heads/") ||
!prefixcmp(name, "tags/") ||
- !prefixcmp(name, "remotes/")) {
- ret = alloc_ref(strlen(name) + 6);
- sprintf(ret->name, "refs/%s", name);
- return ret;
- }
+ !prefixcmp(name, "remotes/"))
+ return alloc_ref_with_prefix("refs/", 5, name);
- ret = alloc_ref(strlen(name) + 12);
- sprintf(ret->name, "refs/heads/%s", name);
- return ret;
+ return alloc_ref_with_prefix("refs/heads/", 11, name);
}
int get_fetch_map(const struct ref *remote_refs,
--
1.6.0.2.542.gde55
^ permalink raw reply related
* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Bert Wesarg @ 2008-10-18 6:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <20081018015010.GA14786@spearce.org>
On Sat, Oct 18, 2008 at 03:50, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Shawn, was there any issue with this one? The patch changes the function
>> signature for no good reason (at least, it does not have anything to do
>> with the stated purpose of the change), but other than that, I think what
>> it attempts to do makes sense.
>
> No, aside from the signature issue I think its reasonable.
Ok, I will post a new single patch, that does only this.
Bert
>
> --
> Shawn.
>
^ permalink raw reply
* Re: externals program, way to do svn:externals-like subproject management without git-submodule
From: Miles Georgi @ 2008-10-18 6:48 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git List
In-Reply-To: <853238710809250037q448046cekc901e5f48acd14a3@mail.gmail.com>
Avery, and to whoever else might be interested in this app:
I have added a freeze feature to ext
It works like this:
ext freeze project_name [revision]
This records the revision in the .externals file under that
subproject's entry. When it is checked out/exported it fetches that
revision.
If you leave the revision off of the command, it uses the revision the
project is currently checked out at.
Also, I got a request to add a cross repository tagging feature, so
that you can create a tag at the top level that remembers
the revisions of all the subprojects at that time. I thought this was
pretty interesting, and could just implement it as a hash
of project to revision numbers/sha1s in a seperate file, perhaps
called .exttags Doesn't seem like it would be hard to implement
now that subprojects can be checked out at specific revisions.
Miles
On Thu, Sep 25, 2008 at 12:37 AM, Miles Georgi <azimux@gmail.com> wrote:
> Avery, and anybody else who might be interested:
>
> I have released a new version of externals which uses the format
> recommended by Avery.
>
> That should make it easier to add new features, such as the ones
> mentioned in Avery's email. I've switched some of my projects to it
> and it seems to be working fine.
> I've bumped the version to 0.1.0 to signify a more betaish stage :)
>
> Miles
>
> On Sat, Sep 13, 2008 at 9:21 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> On Sat, Sep 13, 2008 at 9:06 PM, Miles Georgi <azimux@gmail.com> wrote:
>>> I'll just answer by numbers, I hope it's not too inconvenient to have
>>> to scroll between emails to see which point I'm talking about :/
>>
>> In general, it's better to use inline quoting. It's okay if the
>> quotes get long, because long messages are manageable, but messages
>> that require you to look at *other* messages at the same time are just
>> a PITA. Luckily, however, I at least remember what we're talking
>> about :)
>>
>>> 1. Oh, I'm not really aware of what "cvs export" does. I assumed it
>>> meant something very similar to "svn export" Running "ext export URL"
>>> on a project manage by subversion with all the subprojects managed by
>>> subversion simply runs "svn export URL" followed by an "svn export"
>>> for each subproject, hence the name. Calling it "shallow" makes sense
>>> for git since I'm using --depth 1, but since "svn export" doesn't
>>> create the .svn directories necessary to make it a working directory,
>>> I don't really know if I would call that shallow. For git's
>>> implementation of export, I was thinking of just doing a clone and
>>> then deleting .git/ which also wouldn't be shallow.
>>
>> Aha, sorry. In that case, it does do exactly what cvs export and svn
>> export do, so I take it back. I would never use it (because I always
>> deploy my .git directories along with the app itself... free
>> backups!). But the name is correct.
>>
>>> 3. I am also bothered by the inconsistency of the meaning of [main]
>>> and [git/svn] along with everything you pointed out.
>>>
>>> Question? Is it okay to have "/" characters in the ini section name?
>>
>> Yes. In general, a section name can have anything except a ] in it,
>> and a key can have anything but an = in it. (Well, obviously we
>> should expect that there are no CR, LF, or NUL characters either.)
>>
>> If you want to do it exactly like git, you would name your sections like
>>
>> [ext "libs/my/plugin"]
>>
>> instead of my earlier suggestion of
>>
>> [libs/my/plugin]
>>
>> This would be compatible with git-config. Also, this method means
>> that the [main] section could never be confused with a particular ext
>> section.
>>
>>> I wonder if it would be okay to just put the repository
>>> as the section name. That way scm and path could be excluded for
>>> situations where the defaults are sufficient. Although I guess this
>>> would have the implication of changing a projects repository
>>> (something that happens way more frequently than changing the path
>>> it's installed to) some what messy since it's being identified by its
>>> repository.
>>
>> I think you answered your own question there :) Personally, it feels
>> natural to me to index a submodule by its local path, and have the URL
>> be an attribute of that submodule, rather than the other way around.
>> This makes sense since every local path can only have one submodule on
>> it, while in insane situations, you can imagine having exactly the
>> same repo (perhaps different revisions or branches?) cloned into two
>> different locations.
>>
>>> But yeah, if this feature makes somebody nervous, they can just always
>>> explicitly give the path (which they'll have to do if it's not a rails
>>> app.) It also detects that it's a rails app so it will complain if
>>> you leave the path off in a non-rails app. It won't try to put
>>> something in vendor/plugins of a non-rails app just because a path is
>>> missing.
>>
>> Okay, if it's not in rails mode, I guess it won't cause problems... as
>> long as the rails auto-detection is extremely reliable and can be
>> turned off somehow.
>>
>>> 5. Yeah that's a good idea. I could create a command that adds an
>>> existing subproject to the .externals and updates the ignore properly.
>>> To get this effect at the moment, one would manually add the
>>> subproject to .externals and run "ext update_ignore" I personally
>>> don't usually find myself doing this though. I almost always want the
>>> subproject to be added to the project. I need to make an "ext
>>> uninstall" for backing out if you don't like it. I personally would
>>> rather manually remove the item from .externals than have to issue two
>>> commands to install it. But your idea of a save command is very
>>> powerful, especially with the branch switching ideas you have in #8
>>> below.
>>
>> Right, it wouldn't matter which way you did it, but the other options
>> below fit really nicely into a 'git save' operation.
>>
>> Also, I personally think it's more elegant to not have to do "undo"
>> operations as a normal part of your workflow. Checkout work work work
>> save seems nicer to me than Checkout uninstall work work work.
>>
>> [nested submodules]
>>> 6. Hey that's a pretty interesting idea! I hadn't even thought about
>>> that as I have not yet personally encountered that use case. I've
>>> been hoping that rails plugins could have their own vendor/plugins
>>> directory because if they did I would also use something like that all
>>> the time. This is definitely something that should be implemented at
>>> some point.
>>
>> Well, like I said, I'm doing it right now in one of my projects :)
>> But it doesn't have to be a high priority.
>>
>>> 7. Agreed (for the most part.) I almost never want to do this for my
>>> own projects as I almost always want the branch tip no matter what.
>>> I'd rather run tests and discover that something has broke before
>>> deploying than have to go to all my projects and advance the commit
>>> manually.
>>
>> Ouch, I would never want to do it that way! If my app has been
>> deployed for three months and someone reports a minor bug, I just want
>> to fix that one bug and redeploy safely and immediately. I certainly
>> don't want to risk breaking everything by upgrading a bunch of
>> unrelated modules.
>>
>>> the way I
>>> currently have been handling this is by having my own rails repository
>>> at git://github.com/azimux/rails.git that I occaisionally will merge
>>> rails/rails.git with and run tests for my larger applications. If I
>>> like how it behaves I push the merged tip back out to azimux/rails.git
>>> which is what all my projects reference in their .externals file.
>>
>> This sounds like a convoluted way of just doing what I suggested. :)
>>
>> Oh, that reminds me of another feature that would be awesome:
>> *alternate* repository URLs. In your example above, let's say you've
>> made some rails customizations, anyone cloning your project will have
>> to get your version. But one day, the rails developers merge in your
>> changes, so now their primary repo (probably with more bandwidth,
>> uptime, etc) will work again. If the ext lists *all* the repositories
>> you might need, ext can just git fetch from all of them, then checkout
>> the commit in question, and it will always work.
>>
>>> And I would definitely not
>>> have it disconnected from a branch if it can be avoided. I guess it
>>> would checkout a specific commit but be on a branch, and then if the
>>> developer needed to edit the subproject, they would realize it was
>>> non-fastforward when they pushed and then do a rebase against the
>>> current tip? I'm not 100% sure how this workflow would normally occur
>>> as I've not yet had to rebase anything, and when I was using
>>> git-submodule, I would always checkout a branch tip if I had to edit
>>> the subproject and then would do a git add submodule/path to point at
>>> the new commit when I was done.
>>
>> It can be simpler than that. Essentially, what you do is:
>>
>> git fetch origin
>> git checkout COMMITID
>> git branch -D BRANCHNAME
>> git checkout -b BRANCHNAME
>>
>> The first checkout puts you on a disconnected HEAD temporarily, just
>> in case you were previously on a branch called BRANCHNAME, which would
>> have prevented the "delete branch" operation from working. Then we
>> delete the branch, and recreate it at the new location (COMMITID).
>>
>> With that in place, git will know how to do everything else
>> automatically, but it's up to the user. You can pull/merge the latest
>> changes from another branch, or rebase, etc.
>>
>> Note that as a safety measure, you probably want to refuse to actually
>> do the above if either of:
>> a) The git filesystem or index shows uncommitted files
>> b) The current git commit != the commit ext thinks is checked out right now.
>>
>>> 9. I wasn't planning on having any sort of commit/push-type features
>>> since the workflows of the SCMs are different when it comes to
>>> commiting/pushing. For example, if it's a subversion project it needs
>>> to do an "svn commit" requiring a log message. And sometimes I really
>>> only want to push a subset of the subprojects that I've modified.
>>
>> I think it would be really cool if ext could just figure this out.
>> For example, it's easy to tell that in svn, your changes have to be
>> committed (ie. no dirty tree) and in git, the upstream repo needs to
>> contain your commitid (it's been pushed).
>>
>> If you only want to push a subset of projects, that's fine, but you
>> can do it in the individual subdirs by hand anyhow. On the other
>> hand, I'd say you *don't* want to ever push the parent repo without
>> first pushing all your changes, particularly if you have the commitid
>> encoded in the .externals file, or you'll produce an un-checkout-able
>> repository.
>>
>>> Maybe what I could do is have "ext status" also see if a subproject
>>> could be pushed and issue a warning like "<subproject> has commits
>>> that are missing from <remote name>. Did you forget to push?" This
>>> would be unnecessary for subversion managed subprojects as if it's up
>>> to date, then it's pushed and vice versa, but for git it would be very
>>> helpful for when the status is empty due to commits being performed,
>>> but is not yet pushed out to it's origin.
>>
>> Yes, that would be almost as good.
>>
>>> I don't know if I would
>>> like it automatically doing the pushing though, but it could be
>>> doable, maybe with a command with the name "git" in it to specify it's
>>> scm specific, like "ext gitpush" or I could just have an "ext push"
>>> that does nothing for svn/cvs projects.
>>
>> I don't think it should do nothing for svn/cvs projects: it should
>> either help you commit, or abort with a helpful message if your repo
>> is dirty, or something like that.
>>
>> Hope this helps.
>>
>> Have fun,
>>
>> Avery
>>
>
^ permalink raw reply
* What is the pre-merge hook status?
From: Alexander Gladysh @ 2008-10-18 6:42 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
Hi, Paolo!
What is the status of your pre-merge hook patch?
http://article.gmane.org/gmane.comp.version-control.git/93888
I think it can help me greatly with my repository management process.
Thanks in advance,
Alexander.
^ permalink raw reply
* Re: Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-18 6:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <48F852FC.2070506@viscovery.net>
Thanks for answers, guys.
<...>
> git asked OS X:
>
> Does the file "\312\356\357\350\377.txt" exist?
>
> and OS X said: "Yes". Because otherwise, you would have seen the file
> listed as "deleted:" in the 'git status' call above.
>
> But then git also requested a file listing from OS X in order to list the
> untracked files. And now OS X returned the name "%CA%EE%EF%E8%FF.txt". How
> could you expect git to tell that this is the same file when OS X cannot
> decide how to name it?
>
> The solution: Do not use file names with some local (let alone Windows
> specific) encoding if you have to use the files on OS X, too.
Thank you, but this is not the solution, this is a workaround.
1. Git hooks do not work under msysgit. Thus I'm not able to prevent
people on Windows from committing weird filenames to the repo. (Please
don't start elitist discussion that people using git must do
everything conciously.)
Note also, that even if hooks would work, such files still may appear
in the repo in theory (somebody may disable hooks after all).
2. Now I have one such file. I'm managing my repo on OS X, and have no
access to other machines right now. How can I create commit that
renames the file? Git GUI manages to create commit that adds the
renamed file, but does not delete old one.
Alexander.
^ permalink raw reply
* Re: [PATCH] Documentation: Better explain git-commit --author implications
From: Junio C Hamano @ 2008-10-18 4:55 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git
In-Reply-To: <48F95974.3010503@devslashzero.com>
Abhijit Bhopatkar <bain@devslashzero.com> writes:
> '--author' changes the author name and email, but the
> documentation was not clear that it will not affect the
> '--signoff' option which will still use the user's name and
> email from the git settings.
>
> Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
> ---
> Documentation/git-commit.txt | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index eb05b0f..17b69fa 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -78,7 +78,8 @@ OPTIONS
> Override the author name used in the commit. You can use the
> standard `A U Thor <author@example.com>` format. Otherwise,
> an existing commit that matches the given string and its author
> - name is used.
> + name is used. This has no effect on singoff line which will
> + still use commiter name and email .
>
> -m <msg>::
> --message=<msg>::
> @@ -95,6 +96,7 @@ OPTIONS
> -s::
> --signoff::
> Add Signed-off-by line at the end of the commit message.
> + '--author' option has no effect on this line.
I think it is much clearer if you do not say what does _not_ affect
things, but instead say what does. So let's do this instead.
--signoff::
Add Signed-off-by line by the committer at the end of the commit
log message.
And no other changes.
By making it clear that signoff is about the committer, it would be clear
that --author (or GIT_AUTHOR_NAME environment variable) would not affect
it.
^ permalink raw reply
* rfe: set up tracking the quick way
From: Jan Engelhardt @ 2008-10-18 3:55 UTC (permalink / raw)
To: git
[please cc, but you should do that anyway ;-)]
Hi,
sometimes it happens that I want to issue `git pull`, but then it nicely
tells me that there is no remote branch set up to be tracked (that's my
fault then), and goes on to tell me two longish git config commands to
issue to make it so...
git config branch.master.remote origin
git config branch.master.merge master
76 chars to type. Can we have a short variant? Something like
git track origin/master
or of similar shortness that operates on the current branch.
thanks,
Jan
^ permalink raw reply
* Re: Excluding files from git-diff
From: Christian Jaeger @ 2008-10-18 3:50 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20081017T173145-53@post.gmane.org>
Eric Raible wrote:
> Christian Jaeger <christian <at> pflanze.mine.nu> writes:
>
>
>> Michael J Gruber wrote:
>>
>>> Or put it
>>> in .git/info/excludes.
>>>
>> Only "git ls-files --others --exclude-from=.git/info/exclude" will exclude
>>
>
> Could it be a simple as "excludes" vs "exclude"?
>
Nope.
ln -s exclude .git/info/excludes
git ls-files # still shows files matching the excludes
git ls-files --exclude-from=.git/info/exclude # does not show
git ls-files --exclude-from=.git/info/excludes # does not show
Christian.
^ permalink raw reply
* [PATCH] Documentation: Better explain git-commit --author implications
From: Abhijit Bhopatkar @ 2008-10-18 3:35 UTC (permalink / raw)
To: git; +Cc: gitster
'--author' changes the author name and email, but the
documentation was not clear that it will not affect the
'--signoff' option which will still use the user's name and
email from the git settings.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
---
Documentation/git-commit.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index eb05b0f..17b69fa 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -78,7 +78,8 @@ OPTIONS
Override the author name used in the commit. You can use the
standard `A U Thor <author@example.com>` format. Otherwise,
an existing commit that matches the given string and its author
- name is used.
+ name is used. This has no effect on singoff line which will
+ still use commiter name and email .
-m <msg>::
--message=<msg>::
@@ -95,6 +96,7 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
+ '--author' option has no effect on this line.
-n::
--no-verify::
--
1.5.6.3
^ permalink raw reply related
* Re: Weird filename encoding issue
From: Robin Rosenberg @ 2008-10-18 2:58 UTC (permalink / raw)
To: msysgit; +Cc: Johannes Sixt, Alexander Gladysh, git
In-Reply-To: <48F852FC.2070506@viscovery.net>
fredagen den 17 oktober 2008 10.55.24 skrev Johannes Sixt:
>
> Alexander Gladysh schrieb:
> > 3. Clone repo to OS X machine and see the weird behaviour. Git status
> > can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
> > "\312\356\357\350\377.txt".
>
> It's not 'git status' that cannot decide how to name the file. It's OS X.
>
> > $ git status
> > # On branch master
> > # Untracked files:
> > # (use "git add <file>..." to include in what will be committed)
> > #
> > # %CA%EE%EF%E8%FF.txt
> > nothing added to commit but untracked files present (use "git add" to track)
> > $ ls
> > %CA%EE%EF%E8%FF.txt
>
> git asked OS X:
>
> Does the file "\312\356\357\350\377.txt" exist?
>
> and OS X said: "Yes". Because otherwise, you would have seen the file
> listed as "deleted:" in the 'git status' call above.
>
> But then git also requested a file listing from OS X in order to list the
> untracked files. And now OS X returned the name "%CA%EE%EF%E8%FF.txt". How
> could you expect git to tell that this is the same file when OS X cannot
> decide how to name it?
>
> The solution: Do not use file names with some local (let alone Windows
> specific) encoding if you have to use the files on OS X, too.
That seems to be OS-X's way of saying the is a string of garbage, lets handle it as such.
Git (or msys) under windows is somewhat stupid here as it involves the eight-bit locale
despite running in a unicode OS. To get UTF-8 on XP you can set the codepage to UTF-8
(called 65001 in windows). That might still cause problems with OS-X for some chararacters
as it wants to "decompose" the UTF-8 encoding for accented characters, which perhaps is
not a problem for you.
I have no idea how well codepage 65001 plays with msys, but it would be nice it would work.
I'm not sure how to switch codepage in msys, but if you set it from cmd and then start msys
bash from there, I'm pretty sure it will pick it up.
-- robin
^ permalink raw reply
* Re: Archiving tags/branches?
From: David Symonds @ 2008-10-18 2:50 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <48F93F52.4070506@pcharlan.com>
On Sat, Oct 18, 2008 at 12:43 PM, Pete Harlan <pgit@pcharlan.com> wrote:
> Hi,
>
> I'm looking for a way to manage an ever-growing list of tags. I've read
> some git docs, but am new to git and wonder if the below method doesn't
> work or if there's a standard practice I haven't run into.
>
> Most of the tags in my repo are uninteresting to look at, but can't be
> deleted. (Code releases for the most part, or stalled topic branches.)
> If I wanted to archive those, it looks like this would work:
Is it really true that they can't be deleted? The only reason to avoid
it might be for preventing Git's GC from cleaning them up, but if all
your branches/tags are reachable via "interesting" branches/tags then
you could just slap the tag name and SHA1 in a text file somewhere.
Dave.
^ permalink raw reply
* [PATCH] contrib: update packinfo.pl to not use dashed commands
From: Dan McGee @ 2008-10-18 2:41 UTC (permalink / raw)
To: git; +Cc: Dan McGee
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
contrib/stats/packinfo.pl | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/stats/packinfo.pl b/contrib/stats/packinfo.pl
index f4a7b62..be188c0 100755
--- a/contrib/stats/packinfo.pl
+++ b/contrib/stats/packinfo.pl
@@ -1,9 +1,9 @@
#!/usr/bin/perl
#
# This tool will print vaguely pretty information about a pack. It
-# expects the output of "git-verify-pack -v" as input on stdin.
+# expects the output of "git verify-pack -v" as input on stdin.
#
-# $ git-verify-pack -v | packinfo.pl
+# $ git verify-pack -v | packinfo.pl
#
# This prints some full-pack statistics; currently "all sizes", "all
# path sizes", "tree sizes", "tree path sizes", and "depths".
@@ -20,7 +20,7 @@
#
# When run as:
#
-# $ git-verify-pack -v | packinfo.pl -tree
+# $ git verify-pack -v | packinfo.pl -tree
#
# the trees of objects are output along with the stats. This looks
# like:
@@ -43,7 +43,7 @@
#
# When run as:
#
-# $ git-verify-pack -v | packinfo.pl -tree -filenames
+# $ git verify-pack -v | packinfo.pl -tree -filenames
#
# it adds filenames to the tree. Getting this information is slow:
#
@@ -58,7 +58,7 @@
#
# When run as:
#
-# $ git-verify-pack -v | packinfo.pl -dump
+# $ git verify-pack -v | packinfo.pl -dump
#
# it prints out "sha1 size pathsize depth" for each sha1 in lexical
# order.
@@ -106,7 +106,7 @@ while (<STDIN>) {
}
if ($filenames && ($tree || $dump)) {
- open(NAMES, "git-name-rev --all|");
+ open(NAMES, "git name-rev --all|");
while (<NAMES>) {
if (/^(\S+)\s+(.*)$/) {
my ($sha1, $name) = ($1, $2);
@@ -117,7 +117,7 @@ if ($filenames && ($tree || $dump)) {
for my $commit (@commits) {
my $name = $names{$commit};
- open(TREE, "git-ls-tree -t -r $commit|");
+ open(TREE, "git ls-tree -t -r $commit|");
print STDERR "Plumbing tree $name\n";
while (<TREE>) {
if (/^(\S+)\s+(\S+)\s+(\S+)\s+(.*)$/) {
--
1.6.0.2
^ permalink raw reply related
* Re: "checkout --track -b" broken? (with suggested fix)
From: Daniel Barkalow @ 2008-10-18 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vskqug4fy.fsf@gitster.siamese.dyndns.org>
On Fri, 17 Oct 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Thu, 16 Oct 2008, Junio C Hamano wrote:
> >
> >> The patch to branch.c is a quick fix for this issue. The resulting code
> >> passes all the tests, but I am not very proud of hardcoding the "HEAD" in
> >> the code. There must be a better way to do this.
> >
> > I agree with the change to the test. I think it would be better to
> > hard-code "refs/heads/" instead of "HEAD", and I feel like we must have a
> > "is this ref name a branch?" function, if only because someone could stick
> > "refs/tags/foo" in HEAD, and we should still say it's not something you
> > could track, despite it being something different from "HEAD".
>
> But you can track things under refs/remotes/, so...
Ah, true. Maybe hard-code "refs/". Or have an "is this ref name a branch?"
function that's paying more attention than I am, and returns true from
both local branches and (local copies of) remote branches.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Shawn O. Pearce @ 2008-10-18 1:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, szeder, Bert Wesarg
In-Reply-To: <7vod1ieptr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Shawn, was there any issue with this one? The patch changes the function
> signature for no good reason (at least, it does not have anything to do
> with the stated purpose of the change), but other than that, I think what
> it attempts to do makes sense.
No, aside from the signature issue I think its reasonable.
--
Shawn.
^ permalink raw reply
* Archiving tags/branches?
From: Pete Harlan @ 2008-10-18 1:43 UTC (permalink / raw)
To: git
Hi,
I'm looking for a way to manage an ever-growing list of tags. I've read
some git docs, but am new to git and wonder if the below method doesn't
work or if there's a standard practice I haven't run into.
Most of the tags in my repo are uninteresting to look at, but can't be
deleted. (Code releases for the most part, or stalled topic branches.)
If I wanted to archive those, it looks like this would work:
mkdir .git/refs/archived-tags
cp -a .git/refs/tags/* .git/refs/archived-tags
git tag -d <tag-to-hide> # repeat as necessary
I can then maintain a short list of tags that currently interest me, but
am guaranteed not to lose old branches (say) referenced by those tags.
Is there a reason this won't work?
The immediate downsides I see are:
1. The name "archived-tags" might clash someday with a git directory.
2. I have to manually copy this to clones if I want it there too, and
can't manage it from them remotely.
In general, I'm thinking flat tag and branch namespaces must get
unweildy, and short of implementing directory-style namespace management
within git (e.g., hide tags beginning with "." by default, allow tag
subdirectories) I'm looking for a workaround.
Thanks,
--Pete
^ permalink raw reply
* Re: [PATCH] force_object_loose: Fix memory leak
From: Nicolas Pitre @ 2008-10-18 1:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20081018003731.GA17290@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2064 bytes --]
On Sat, 18 Oct 2008, Björn Steinbrink wrote:
> read_packed_sha1 expectes its caller to free the buffer it returns, which
> force_object_loose didn't do.
>
> This leak is eventually triggered by "git gc", when it is manually invoked
> or there are too many packs around, making gc totally unusable when there
> are lots of unreachable objects.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Good catch.
Acked-by: Nicolas Pitre <nico@cam.org>
> ---
> Tested with a somewhat recent clone of linux-2.6.git:
>
> git clone linux-2.6 test
> cd test
> git remote rm origin
> git reset --hard v2.6.16
> git for-each-ref --format='%(refname)' refs/tags | \
> xargs -i git update-ref -d {}
> git reflog expire --expire=0 --all
> git repack -Ad
>
> Without the fix, I killed repack when its memory usage got past 3 _GB_.
> With the fix, it stays at around 300MB until it starts writing the
> new pack, then it goes up to about 550MB or so.
>
> sha1_file.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 3fbb082..70bb453 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2333,6 +2333,7 @@ int force_object_loose(const unsigned char *sha1, time_t mtime)
> enum object_type type;
> char hdr[32];
> int hdrlen;
> + int ret;
>
> if (has_loose_object(sha1))
> return 0;
> @@ -2340,7 +2341,10 @@ int force_object_loose(const unsigned char *sha1, time_t mtime)
> if (!buf)
> return error("cannot read sha1_file for %s", sha1_to_hex(sha1));
> hdrlen = sprintf(hdr, "%s %lu", typename(type), len) + 1;
> - return write_loose_object(sha1, hdr, hdrlen, buf, len, mtime);
> + ret = write_loose_object(sha1, hdr, hdrlen, buf, len, mtime);
> + free(buf);
> +
> + return ret;
> }
>
> int has_pack_index(const unsigned char *sha1)
> --
> 1.6.0.2.541.g46dc1.dirty
> --
> 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
>
Nicolas
^ permalink raw reply
* [PATCH] parse-opt: migrate builtin-checkout-index.
From: Miklos Vajna @ 2008-10-18 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7v63nqg4f4.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-checkout-index.c | 152 +++++++++++++++++++++++++---------------------
1 files changed, 83 insertions(+), 69 deletions(-)
On Fri, Oct 17, 2008 at 04:58:23PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > + { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
> > + "paths are separated with NUL character",
> > + PARSE_OPT_NOARG, option_parse_z },
>
> This adds a new feature to say --no-z from the command line, doesn't
> it?
> And I suspect the feature is broken ;-).
Right, I fixed this in option_parse_z(). --no-z should set
line_termination to \n instead of 1.
> > + OPT_BOOLEAN(0, "stdin", &read_from_stdin,
> > + "read list of paths from the standard input"),
> > ...
> > + argc = parse_options(argc, argv, builtin_checkout_index_options,
> > + builtin_checkout_index_usage, 0);
> > + state.force = force;
> > + state.quiet = quiet;
> > + state.not_new = not_new;
> > + if (argc && read_from_stdin)
> > + die("--stdin must be at the end");
>
> Is this comment still correct? Do the original and your version act
> the
> same way when the user says "checkout --stdin -f", for example? I
> suspect
> the original refused it and yours take it (and do much more sensible
> thing), which would be an improvement, but then the error message
> should
> be reworded perhaps?
Unless I missed something, that was a limitation of the option parser.
checkout-index --stdin -f works fine for me after removing those two
lines, so I left them out from the updated patch.
diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index 4ba2702..0d534bc 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -40,6 +40,7 @@
#include "cache.h"
#include "quote.h"
#include "cache-tree.h"
+#include "parse-options.h"
#define CHECKOUT_ALL 4
static int line_termination = '\n';
@@ -153,11 +154,58 @@ static void checkout_all(const char *prefix, int prefix_length)
exit(128);
}
-static const char checkout_cache_usage[] =
-"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
+static const char * const builtin_checkout_index_usage[] = {
+ "git checkout-index [options] [--] <file>...",
+ NULL
+};
static struct lock_file lock_file;
+static int option_parse_u(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *newfd = opt->value;
+
+ state.refresh_cache = 1;
+ if (*newfd < 0)
+ *newfd = hold_locked_index(&lock_file, 1);
+ return 0;
+}
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (unset)
+ line_termination = '\n';
+ else
+ line_termination = 0;
+ return 0;
+}
+
+static int option_parse_prefix(const struct option *opt,
+ const char *arg, int unset)
+{
+ state.base_dir = arg;
+ state.base_dir_len = strlen(arg);
+ return 0;
+}
+
+static int option_parse_stage(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (!strcmp(arg, "all")) {
+ to_tempfile = 1;
+ checkout_stage = CHECKOUT_ALL;
+ } else {
+ int ch = arg[0];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[0] - '0';
+ else
+ die("stage should be between 1 and 3 or all");
+ }
+ return 0;
+}
+
int cmd_checkout_index(int argc, const char **argv, const char *prefix)
{
int i;
@@ -165,6 +213,33 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
int all = 0;
int read_from_stdin = 0;
int prefix_length;
+ int force = 0, quiet = 0, not_new = 0;
+ struct option builtin_checkout_index_options[] = {
+ OPT_BOOLEAN('a', "all", &all,
+ "checks out all files in the index"),
+ OPT_BOOLEAN('f', "force", &force,
+ "forces overwrite of existing files"),
+ OPT__QUIET(&quiet),
+ OPT_BOOLEAN('n', "no-create", ¬_new,
+ "don't checkout new files"),
+ { OPTION_CALLBACK, 'u', "index", &newfd, NULL,
+ "update stat information in the index file",
+ PARSE_OPT_NOARG, option_parse_u },
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_BOOLEAN(0, "stdin", &read_from_stdin,
+ "read list of paths from the standard input"),
+ OPT_BOOLEAN(0, "temp", &to_tempfile,
+ "write the content to temporary files"),
+ OPT_CALLBACK(0, "prefix", NULL, "string",
+ "when creating files, prepend <string>",
+ option_parse_prefix),
+ OPT_CALLBACK(0, "stage", NULL, NULL,
+ "copy out the files from named stage",
+ option_parse_stage),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
state.base_dir = "";
@@ -174,72 +249,11 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
die("invalid cache");
}
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (!strcmp(arg, "--")) {
- i++;
- break;
- }
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all")) {
- all = 1;
- continue;
- }
- if (!strcmp(arg, "-f") || !strcmp(arg, "--force")) {
- state.force = 1;
- continue;
- }
- if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
- state.quiet = 1;
- continue;
- }
- if (!strcmp(arg, "-n") || !strcmp(arg, "--no-create")) {
- state.not_new = 1;
- continue;
- }
- if (!strcmp(arg, "-u") || !strcmp(arg, "--index")) {
- state.refresh_cache = 1;
- if (newfd < 0)
- newfd = hold_locked_index(&lock_file, 1);
- continue;
- }
- if (!strcmp(arg, "-z")) {
- line_termination = 0;
- continue;
- }
- if (!strcmp(arg, "--stdin")) {
- if (i != argc - 1)
- die("--stdin must be at the end");
- read_from_stdin = 1;
- i++; /* do not consider arg as a file name */
- break;
- }
- if (!strcmp(arg, "--temp")) {
- to_tempfile = 1;
- continue;
- }
- if (!prefixcmp(arg, "--prefix=")) {
- state.base_dir = arg+9;
- state.base_dir_len = strlen(state.base_dir);
- continue;
- }
- if (!prefixcmp(arg, "--stage=")) {
- if (!strcmp(arg + 8, "all")) {
- to_tempfile = 1;
- checkout_stage = CHECKOUT_ALL;
- } else {
- int ch = arg[8];
- if ('1' <= ch && ch <= '3')
- checkout_stage = arg[8] - '0';
- else
- die("stage should be between 1 and 3 or all");
- }
- continue;
- }
- if (arg[0] == '-')
- usage(checkout_cache_usage);
- break;
- }
+ argc = parse_options(argc, argv, builtin_checkout_index_options,
+ builtin_checkout_index_usage, 0);
+ state.force = force;
+ state.quiet = quiet;
+ state.not_new = not_new;
if (state.base_dir_len || to_tempfile) {
/* when --prefix is specified we do not
@@ -253,7 +267,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
}
/* Check out named files first */
- for ( ; i < argc; i++) {
+ for (i = 0; i < argc; i++) {
const char *arg = argv[i];
const char *p;
--
1.6.0.2
^ permalink raw reply related
* [PATCH] force_object_loose: Fix memory leak
From: Björn Steinbrink @ 2008-10-18 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
read_packed_sha1 expectes its caller to free the buffer it returns, which
force_object_loose didn't do.
This leak is eventually triggered by "git gc", when it is manually invoked
or there are too many packs around, making gc totally unusable when there
are lots of unreachable objects.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
Tested with a somewhat recent clone of linux-2.6.git:
git clone linux-2.6 test
cd test
git remote rm origin
git reset --hard v2.6.16
git for-each-ref --format='%(refname)' refs/tags | \
xargs -i git update-ref -d {}
git reflog expire --expire=0 --all
git repack -Ad
Without the fix, I killed repack when its memory usage got past 3 _GB_.
With the fix, it stays at around 300MB until it starts writing the
new pack, then it goes up to about 550MB or so.
sha1_file.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 3fbb082..70bb453 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2333,6 +2333,7 @@ int force_object_loose(const unsigned char *sha1, time_t mtime)
enum object_type type;
char hdr[32];
int hdrlen;
+ int ret;
if (has_loose_object(sha1))
return 0;
@@ -2340,7 +2341,10 @@ int force_object_loose(const unsigned char *sha1, time_t mtime)
if (!buf)
return error("cannot read sha1_file for %s", sha1_to_hex(sha1));
hdrlen = sprintf(hdr, "%s %lu", typename(type), len) + 1;
- return write_loose_object(sha1, hdr, hdrlen, buf, len, mtime);
+ ret = write_loose_object(sha1, hdr, hdrlen, buf, len, mtime);
+ free(buf);
+
+ return ret;
}
int has_pack_index(const unsigned char *sha1)
--
1.6.0.2.541.g46dc1.dirty
^ permalink raw reply related
* Re: Fwd: git status options feature suggestion
From: Fyn Fynn @ 2008-10-18 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <ee2a733e0810120309o1fbfa4dxe6f2292a28bd6db3@mail.gmail.com>
Just wanted to chime in about a feature existing in Bazaar's and
Subversion's and "status" command: getting the status of tracked
files _only_.
Here's how the status -V switch works in Bazaar:
~/foo$ bzr init
~/foo$ echo "content" > bar.txt
~/foo$ bzr add bar.txt
added bar.txt
~/foo$ echo "content" > baz.txt
~/foo$ bzr status
added:
bar.txt
unknown:
baz.txt
~/foo$ bzr status -V
added:
bar.txt
As you can see, the -V switch makes `bzr status` only display the
status of files that are tracked.
This is very useful when you're tracking a "skeleton" of essential
files in a directory tree that contains a large number of additional
files and subdirectories, particularly if those are changing often and
/ or are large/binary so it's impractical to control/ignore them.
A common case of that: tracking a subset of configuration files under
one's home directory.
Right now, there are two ways of getting around the lack of "status
-V" (Subversion: "status -q") in git (credit for both goes to doener
on #git@FreeNode, who showed them to me):
git config --global alias.st 'diff --name-status HEAD'
Which makes `git st` output practically the same thing as -V/-q in
Bazaar/Subversion. However, the output doesn't distinguish between
Staged (indexed) and Unstaged (non-indexed) changes (a distinction
that the 2 other SCMs above don't support).
git config --global alias.st '!echo Staged:; git diff --cached
--name-status; echo Unstaged:; git diff --name-status'
Which does distinguish between Staged and Unstaged, but is definitely
something that can work only as an alias for frequent usage.
Incidentally, a minor quibble with both solutions is that they require
HEAD to exist; so you need to make at least one commit before you can
use them. For most users, this wouldn't frequently be a huge loss, but
if you're commonly initializing branches, you might miss it. For
example, note how the above Bazaar example would fail with:
fatal: ambiguous argument 'HEAD': unknown revision or path not in the
working tree.
- Fyn
^ permalink raw reply
* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Junio C Hamano @ 2008-10-17 23:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, szeder, Bert Wesarg
In-Reply-To: <1222074591-26548-1-git-send-email-bert.wesarg@googlemail.com>
Shawn, was there any issue with this one? The patch changes the function
signature for no good reason (at least, it does not have anything to do
with the stated purpose of the change), but other than that, I think what
it attempts to do makes sense.
^ 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