* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Jay Soffian @ 2011-10-05 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, nicolas.dichtel
In-Reply-To: <7v8voz8hgq.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Pinging Jay who may have know a thing or two from the history leading to
> 37f7a85 (Teach commit about CHERRY_PICK_HEAD, 2011-02-19).
Yep, I replied to Nicolas' other message.
j.
^ permalink raw reply
* Re: [BUG] git stash -k show the help message for diff-index
From: Junio C Hamano @ 2011-10-05 17:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfwj7v5cx.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Everything is in the title. No time to bisect/fix this now, but:
>
> $ git status
> # On branch master
> nothing to commit (working directory clean)
> $ git stash -k
> usage: git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
Hmm, does not reproduce.
: alter victim-2.git/master; git status
# On branch master
nothing to commit (working directory clean)
: alter victim-2.git/master; git stash -k
No local changes to save
: alter victim-2.git/master; git version
git version 1.7.7
^ permalink raw reply
* Re: git-cherry-pick and author field in version 1.7.6.4
From: Jeff King @ 2011-10-05 17:41 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: git
In-Reply-To: <4E8C6F0E.7000508@6wind.com>
On Wed, Oct 05, 2011 at 04:51:58PM +0200, Nicolas Dichtel wrote:
> in the last stable version (1.7.6.4), when I perform a
> git-cherry-pick, the initial author of the patch is erased whith my
> name (it was not the case in version 1.7.3.4 and prior). Is this
> behavior intended ? Is there an option to keep the initial author of
> the patch?
I can't reproduce your problem:
git init repo &&
cd repo &&
echo content >file && git add file && git commit -m base &&
echo changes >>file &&
git commit --author='Other Person <other@example.com>' -a -m other &&
git tag other &&
git reset --hard HEAD^ &&
git cherry-pick other
gives this output for the cherry-pick:
[master 6eb207f] other
Author: Other Person <other@example.com>
1 files changed, 1 insertions(+), 0 deletions(-)
and the resulting commit looks good:
$ git log -1 --format='%an <%ae>'
Other Person <other@example.com>
Does the script above work for you? If so, then what is different about
your problematic case?
-Peff
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Junio C Hamano @ 2011-10-05 17:40 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel
In-Reply-To: <4E8C6F2F.1070306@6wind.com>
Pinging Jay who may have know a thing or two from the history leading to
37f7a85 (Teach commit about CHERRY_PICK_HEAD, 2011-02-19).
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Hi,
>
> still with version 1.7.6.4, when I do a cherry-pick, that succeeded, I
> cannot do a commit --amend after:
>
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 1a04a23] drivers/net/usb/asix.c: Fix unaligned accesses
> 1 files changed, 33 insertions(+), 1 deletions(-)
> # echo $?
> 0
> # git commit --amend
> fatal: You are in the middle of a cherry-pick -- cannot amend.
> #
>
> The same operations (with the same patch), with version 1.7.3.4 is ok.
>
>
> Regards,
> Nicolas
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Junio C Hamano @ 2011-10-05 17:38 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Gioele Barabucci, git
In-Reply-To: <4E8C481A.1070808@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Indeed, your use case is broken by
>
> f5114a40c0d0276ce6ff215a3dc51eb19da5b420
>
> In fact the support for gitattributes using patterns involving "." was
> pretty spotty in v1.7.6 too. For example,
> ...
> I conclude that this functionality was never really defined correctly,
> and you were pretty lucky that your case worked at all :-)
The attribute patterns (or exclude patterns for that matter) were never
designed to name "the current directory". The way to name "everything *in*
this directory" has always been to say "*" (the "* text=auto" example in
the documentation says it shows how to set the attribute "for all
files"). Admittedly the pattern may miss ".*" files.
I have to agree that things like "./" and "." were outside the scope of
the design; in some cases undefined behaviour given to such patterns may
have made sense but that was mere accident.
If we were to give some defined behaviour to these patterns, updating the
"Pattern Format" section of Documentation/gitignore.txt is the first thing
to do. The text currently reads like this:
PATTERN FORMAT
--------------
- A blank line matches no files, so it can serve as a separator
for readability.
- A line starting with # serves as a comment.
- An optional prefix '!' which negates the pattern; any
matching file excluded by a previous pattern will become
included again. If a negated pattern matches, this will
override lower precedence patterns sources.
- If the pattern ends with a slash, it is removed for the
purpose of the following description, but it would only find
a match with a directory. In other words, `foo/` will match a
directory `foo` and paths underneath it, but will not match a
regular file or a symbolic link `foo` (this is consistent
with the way how pathspec works in general in git).
- If the pattern does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
pathname relative to the location of the `.gitignore` file
(relative to the toplevel of the work tree if not from a
`.gitignore` file).
- Otherwise, git treats the pattern as a shell glob suitable
for consumption by fnmatch(3) with the FNM_PATHNAME flag:
wildcards in the pattern will not match a / in the pathname.
For example, "Documentation/{asterisk}.html" matches
"Documentation/git.html" but not "Documentation/ppc/ppc.html"
or "tools/perf/Documentation/perf.html".
- A leading slash matches the beginning of the pathname.
For example, "/{asterisk}.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".
I think adding the following before the 5th rule ("If the pattern does not
contain a slash") would be sufficient:
- If the pattern is a single dot and nothing else, it matches everything
in the current directory.
So "./" in .gitignore or .gitattributes at the toplevel would match all
the top-level directories and files but does not apply to the paths
contained in the matched directories. "." in .gitignore or .gitattributes
at the toplevel would match everything under the sun.
Personally I do not think it is an improvement. You can certainly say "we
have one less undefined case and are more consistent", but the downside of
that consistency is that it is very confusing and error prone for the end
users. Would it be sensible to assume that users would not be surprised if
". text=auto" meant that the attribute applies to every file in the
worktree?
^ permalink raw reply
* Re: [PATCH WIP 0/3] git log --exclude
From: Junio C Hamano @ 2011-10-05 17:20 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1317799088-26626-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This series adds --exclude that uses .gitignore mechanism remove
> commits whose changes that are _entirely_ excluded.
I really do not want to see the exclude patterns nor mechanism used for
this. This will unnecessarily impact the long term design of narrow clones
I had in mind.
The way I envisioned the narrow cloning would work like this [*1*]:
* The narrowed set of paths is an attribute of the local repository. It
is not tied to the history nor the current working tree state, so the
information does not live in the index or in the history. A new file
$GIT_DIR/narrowed-paths specifies a list of pathspecs. We call a
repository with such a file "a narrowed repository".
* The objects that live in a narrowed repository are subset of the
objects in an unnarrowed repository that records the same
history. Objects are not modified in any way when transferring into
a narrowed repository. E.g. if you clone git.git but limit the tree to
Documentation/ and builtin/, you will get _all_ commit objects, even
the ones that do _not_ touch these two directories, and the top level
tree objects. These top level tree objects _do_ record the object names
for paths outside the narrowed area. To facilitate local history
traversal, we may add either grafts or replace entries to "gather" away
commits that do not touch the narrowed area, but this is not essential.
* "struct pathspec" gains a handful of new fields to carry the set of
narrowing pathspecs taken from $GIT_DIR/narrowed-paths file down the
callchain. When we decide to see if a given path matches the pathspec
and/or is worth descending into, we use these pathspecs to reject
anything that is outside of the narrowed area before applying user
supplied pathspec. We use narrowing pathspecs even for the whole tree
operation.
* "fsck", "prune" and friends that do not use user-supplied pathspec will
learn the narrowed-paths so that the tree entries that describe objects
outside the narrowed area (e.g. "Makefile" in the top-level tree in a
repository narrowed to "Documentation/" and "builtin/") are ignored.
I looked at fsck and unpack-objects (surprise, but it does seem to need
some work) a few months ago for this exact purpose, and it appeared
doable.
We may want to be able to say something like "I want Documentation/ but
not Documentaion/howto/", and for that to work, narrowed-paths needs to be
able to express negative matches. And in _that_ context, we will need
negative pathspec matches (and I think during the last round of pathspec
updates we identified where the support for ":(no):pathspec" needs to be
added in the codepath).
You could say "Use pathspec for inclusion and ignore patterns for
exclusion", but I do not think that inconsistency has merits.
For the purpose of "log --exclude" [*2*], I do not mind too much if the UI
expressed negative pathspecs using such a new command line option, but I
think it would be more natural to say (notations aside):
$ git log -- ':(no):po' .
and define the behaviour of user-supplied pathspec limiter this way:
* Paths are matched from left to right;
* First match determines the fate of the path;
* A match with negative pathspec means "the path in question does _not_
match".
[Footnote]
*1* Unlike the "This is _one_ possible way" I usually give in discussions,
this is "The narrow clone _must_ work like this, if we were to add it".
*2* I would suggest not using --exclude to avoid giving users a wrong
impression that this might have something to do with exclude patterns. How
about calling it "--filter-out" instead?
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vpqib8jzk.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 12:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> In this case, each workdir needs its own key, so I'd have to record
>> the key somewhere, unless you meant using a key of "checkout:
>> </path/to/workdir>".
>
> That actually is how I read his message.
>
> I do not think "we cannot off the top of our heads think of the reason
> other than the branch is checked out that we might want to forbid its
> update" is a very good excuse to cast the word "checkout" in the UI; you
> would paint yourself in a difficult corner that you have to expend more
> energy to get out of by later adding backward compatibility support.
Git has survived w/o needing to lock branches till now. What are these
use cases we cannot already think of today?
> I think "switch_branches()" that updates HEAD to point at a local branch
> is one good place to lock the branch, but I do not know if it is a good
> idea to hook the check into the codepaths for deletion of the branch using
> "branch -[dD]" and check-out of the branch using "checkout $branch". I
> wonder if it makes sense to add the "checking" hook into much lower level
> in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
> catch attempts to update "your" current branch by other people.
I don't think so. There are lots of ways to shoot yourself in the foot
at the plumbing level. Besides, this is not about all refs, just local
branches.
Aside, there's nothing wrong with renaming a checked out branch.
> For that
> matter, instead of switch_branches(), would it make more sense to add this
> lock/unlock logic to symbolic_ref() that repoints HEAD to other branch?
I think you mean create_symref()? Looking at it's callers that seems
too low-level.
Maybe you could sketch out how you think this should work, I'm not seeing it.
- Where/how should the lock be recorded?
- Which function(s) should record/release the lock?
j.
^ permalink raw reply
* Re: git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Jay Soffian @ 2011-10-05 16:50 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: git
In-Reply-To: <4E8C6F2F.1070306@6wind.com>
On Wed, Oct 5, 2011 at 10:52 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Hi,
>
> still with version 1.7.6.4, when I do a cherry-pick, that succeeded, I
> cannot do a commit --amend after:
>
> # git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
> [dev 1a04a23] drivers/net/usb/asix.c: Fix unaligned accesses
> 1 files changed, 33 insertions(+), 1 deletions(-)
> # echo $?
> 0
> # git commit --amend
> fatal: You are in the middle of a cherry-pick -- cannot amend.
> #
>
> The same operations (with the same patch), with version 1.7.3.4 is ok.
Please do the following with 1.7.6.4:
# ls .git
# git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
# ls .git
# git cat-file -p 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
# git cat-file -p HEAD
And send the transcript.
Thanks.
j.
^ permalink raw reply
* Re: Git Bug report
From: Junio C Hamano @ 2011-10-05 16:49 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Federico Lucifredi, git
In-Reply-To: <20111005072235.GA12600@kolya>
Fredrik Gustafsson <iveqy@iveqy.com> writes:
> On Tue, Oct 04, 2011 at 05:24:03PM -0400, Federico Lucifredi wrote:
>> Found a minor bug in git today - the error message reported is not
>> correct when trying to access a repo that is not accessible
>> permission-wise:
>>
>> > federico@skyplex:/etc$ git log
>> > fatal: Not a git repository (or any of the parent directories): .git
>>
>> with correct access permissions, everything works as expected.
>
> So if:
> .git/ is a directory with not enought permissions.
> ../.git/ is a directory with enought permissions.
>
> git would today use ../.git. You suggest that git instead would die
> because a .git/ exists? (I'm not saying this is wrong or right).
For that matter, if you have .git/ that is a directory but is not a
repository, and ../.git/ that is, the same situation would arise. I do not
think we should die because .git/ is not a git repository. I do not know
if we should even warn about it.
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 16:46 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_DygQTD5ibco=-NOiKg0BLgBGFJnvV8zPyhngC2iZv_H8g@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Wed, Oct 5, 2011 at 12:02 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> Could you please consider a more generic approach? What I have in mind
>> is a mechanism to "lock" a branch, so that only commands that have the
>> key can update it.
>>
>> So instead of branch.<name>.checkout, I would have something like
>> branch.<name>.locked = <key>, where <key> is just a string. Only
>> commands that provide the matching <key> are allowed to update the
>> branch. In checkout case, <key> could be "checkout: worktree".
>
> In this case, each workdir needs its own key, so I'd have to record
> the key somewhere, unless you meant using a key of "checkout:
> </path/to/workdir>".
That actually is how I read his message.
I do not think "we cannot off the top of our heads think of the reason
other than the branch is checked out that we might want to forbid its
update" is a very good excuse to cast the word "checkout" in the UI; you
would paint yourself in a difficult corner that you have to expend more
energy to get out of by later adding backward compatibility support.
I think "switch_branches()" that updates HEAD to point at a local branch
is one good place to lock the branch, but I do not know if it is a good
idea to hook the check into the codepaths for deletion of the branch using
"branch -[dD]" and check-out of the branch using "checkout $branch". I
wonder if it makes sense to add the "checking" hook into much lower level
in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
catch attempts to update "your" current branch by other people. For that
matter, instead of switch_branches(), would it make more sense to add this
lock/unlock logic to symbolic_ref() that repoints HEAD to other branch?
^ permalink raw reply
* Notes workflow improvements
From: Stephen Bash @ 2011-10-05 16:35 UTC (permalink / raw)
To: git discussion list
Hi all-
At a developer meeting this morning, several of my coworkers expressed interest in using (shared) git notes in our workflow. I dug back in the mail archive and found a discussion started by Yann [1] and a patch series [2] that would help the notes workflow.
Unfortunately I'm not finding any further reference to the patch series in the mail archive or in Junio's alt-git repo. Does anyone know the status of this patch series?
[1] http://article.gmane.org/gmane.comp.version-control.git/175688
[2] http://article.gmane.org/gmane.comp.version-control.git/175983
Thanks!
Stephen
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2011, #01; Tue, 4)
From: Junio C Hamano @ 2011-10-05 16:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4E8BFF26.5050504@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 10/5/2011 4:12, schrieb Junio C Hamano:
>> * il/archive-err-signal (2011-10-03) 1 commit
>> - transport: do not allow to push over git:// protocol
>
> Kindly fix up the commit message (delete the cruft) before you merge to next.
Thanks for noticing.
^ permalink raw reply
* Re: [PATCH 3/3] Windows: teach getenv to do a case-sensitive search
From: Karsten Blees @ 2011-10-05 16:21 UTC (permalink / raw)
To: git
In-Reply-To: <4DEC7CDD.10403@viscovery.net>
Hmm...this looks like a pretty fragile solution to me. Wouldn't it be simpler
and safer to just fix the conflicting variables, instead of inventing entirely
new environment semantics for Windows?
I looked at the eval_gettext occurences, and only found '$path' in
git-submodule.sh to obviously conflict with existing environment variables. So
the straightforward solution IMO would be to fix the variable in that script.
Small solution (only affects gettext): in git-submodule.sh, replace all
'eval_gettext...$path' with 'modulepath=$path eval_gettext...$modulepath'
Big solution (enables git-submodule-foreach scripts on Windows, but is a
breaking change for existing foreach scripts on Unix): in git-submodule.sh,
t/t7407-submodule-foreach.sh, Documentation/git-submodule.txt, replace all
'$path' with '$modulepath' (also a few 'path=...' and 'while read...path')
Just a few failure scenarios that come to mind with the current solution:
- Given environment variables "Path" and "path", the 'case-sensitive first'
approach works fine for 'getenv("path")', but 'getenv("PATH")' still has a 50%
chance of failure.
- The other environment functions have not been changed to reflect the
'case-sensitive first' logic: setenv("path"...) and setenv("PATH"...) both have
a chance of overwriting the wrong entry, same for putenv.
- Windows applications generally don't support case-sensitive environment
variables, e.g. all MSYS and Cygwin programs convert environment variable names
to upper case on startup, eliminating duplicates in the process. With git.exe
beeing the only case-sensitive tool, any change to git-sh-i18n.sh (e.g.
replacing git-envsubst with a real gettext-envsubst) is likely to break again.
- As you already mentioned, Windows doesn't support case-sensitive environment
variable names, MSDN is pretty clear on that. Expressly violating this
documentation may cease to work with any new Windows version or patch.
Cheers,
Karsten
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 16:01 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Nguyen Thai Ngoc Duy, Junio C Hamano
In-Reply-To: <1317828285-66581-1-git-send-email-jaysoffian@gmail.com>
> I was more looking for feedback on the idea than the implementation, but
> here's a better implementation. Still an RFC so no tests yet.
Oops. Let's try that again. Sent the wrong thing.
-- >8 --
Subject: [RFC/PATCH] Teach branch/checkout about workdirs
When using 'git new-workdir', there is no safety mechanism to prevent the
same branch from being checked out twice, nor to prevent a checked out
branch from being deleted.
Teach 'checkout' to record the workdir path using 'branch.<name>.checkout'
when switching branches. We can then easily check if a branch is already
checked out in another workdir before switching to that branch. Add a
similar check before deleting a branch.
Allow 'checkout -f' to force the checkout and issue a warning instead of
an error.
Guard this behavior behind 'core.recordCheckouts', which we will teach
'git new-workdir' to set in a followup commit.
Note: when switching away from a branch, we set 'branch.<name>.checkout'
to the empty string, instead of deleting it entirely, since git_config()
otherwise leaves behind an empty section which it does not re-use.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
builtin/branch.c | 10 ++++++++++
builtin/checkout.c | 43 +++++++++++++++++++++++++++++++++++++++++++
remote.c | 4 ++++
remote.h | 1 +
4 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index f49596f826..6ce1a5b133 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -182,6 +182,16 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
ret = 1;
continue;
}
+ if (kinds == REF_LOCAL_BRANCH) {
+ struct branch *branch = branch_get(bname.buf);
+ if (branch->work_tree && strlen(branch->work_tree)) {
+ error(_("Cannot delete the branch '%s' "
+ "which is currently checked out in '%s'"),
+ bname.buf, branch->work_tree);
+ ret = 1;
+ continue;
+ }
+ }
free(name);
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5e356a6c61..75510befde 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -33,6 +33,7 @@ struct checkout_opts {
int force_detach;
int writeout_stage;
int writeout_error;
+ int record_checkouts;
/* not set by parse_options */
int branch_exists;
@@ -508,6 +509,21 @@ static void detach_advice(const char *old_path, const char *new_name)
fprintf(stderr, fmt, new_name);
}
+static void record_checkout(const char *name, const char *new_work_tree)
+{
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(&key, "branch.%s.checkout", name);
+ if (new_work_tree) { /* reserve name */
+ git_config_set(key.buf, new_work_tree);
+ } else { /* release name if we reserved it */
+ struct branch *branch = branch_get(name);
+ if (branch->work_tree &&
+ !strcmp(branch->work_tree, get_git_work_tree()))
+ git_config_set(key.buf, "");
+ }
+ strbuf_release(&key);
+}
+
static void update_refs_for_switch(struct checkout_opts *opts,
struct branch_info *old,
struct branch_info *new)
@@ -556,6 +572,8 @@ static void update_refs_for_switch(struct checkout_opts *opts,
detach_advice(old->path, new->name);
describe_detached_head(_("HEAD is now at"), new->commit);
}
+ if (opts->record_checkouts && old->name)
+ record_checkout(old->name, NULL);
} else if (new->path) { /* Switch branches. */
create_symref("HEAD", new->path, msg.buf);
if (!opts->quiet) {
@@ -580,6 +598,11 @@ static void update_refs_for_switch(struct checkout_opts *opts,
if (!file_exists(ref_file) && file_exists(log_file))
remove_path(log_file);
}
+ if (opts->record_checkouts) {
+ if (old->name)
+ record_checkout(old->name, NULL);
+ record_checkout(new->name, get_git_work_tree());
+ }
}
remove_branch_state();
strbuf_release(&msg);
@@ -709,6 +732,20 @@ static void orphaned_commit_warning(struct commit *commit)
for_each_ref(clear_commit_marks_from_one_ref, NULL);
}
+static void check_if_checked_out(struct checkout_opts *opts, const char *name)
+{
+ struct branch *branch = branch_get(name);
+ if (branch->work_tree && strlen(branch->work_tree) &&
+ strcmp(branch->work_tree, get_git_work_tree())) {
+ if (opts->force)
+ warning(_("branch '%s' is currently checked out"
+ " in '%s'"), name, branch->work_tree);
+ else
+ die(_("branch '%s' is currently checked out"
+ " in '%s'"), name, branch->work_tree);
+ }
+}
+
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
{
int ret = 0;
@@ -732,6 +769,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
if (!new->commit)
die(_("You are on a branch yet to be born"));
parse_commit(new->commit);
+ } else if (opts->record_checkouts) {
+ check_if_checked_out(opts, new->name);
}
ret = merge_working_tree(opts, &old, new);
@@ -756,6 +795,10 @@ static int git_checkout_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "core.recordcheckouts")) {
+ struct checkout_opts *opts = cb;
+ opts->record_checkouts = git_config_bool(var, value);
+ }
if (!prefixcmp(var, "submodule."))
return parse_submodule_config_option(var, value);
diff --git a/remote.c b/remote.c
index b8ecfa5d95..2bc063dae8 100644
--- a/remote.c
+++ b/remote.c
@@ -364,6 +364,10 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!value)
return config_error_nonbool(key);
add_merge(branch, xstrdup(value));
+ } else if (!strcmp(subkey, ".checkout")) {
+ if (!value)
+ return config_error_nonbool(key);
+ branch->work_tree = xstrdup(value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 9a30a9dba6..4103ec7e31 100644
--- a/remote.h
+++ b/remote.h
@@ -126,6 +126,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec);
struct branch {
const char *name;
const char *refname;
+ const char *work_tree;
const char *remote_name;
struct remote *remote;
--
1.7.7.5.gd207e.dirty
^ permalink raw reply related
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 15:24 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Jay Soffian, Nguyen Thai Ngoc Duy
In-Reply-To: <7vmxdg9j3r.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 12:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> @@ -734,6 +758,9 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
>> parse_commit(new->commit);
>> }
>>
>> + if (opts->record_checkouts)
>> + check_if_checked_out(opts, new->name);
>
> The close brace we can see in the context closes "if (!new->name) {", so
> this codepath is very well prepared to be called with new->name == NULL.
>
> Is check_if_checked_out() prepared to be called with name == NULL and do
> the right thing?
>
>> @@ -743,6 +770,14 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
>>
>> update_refs_for_switch(opts, &old, new);
>>
>> + if (opts->record_checkouts) {
>> + const char *work_tree = get_git_work_tree();
>> + struct branch *branch = branch_get(old.name);
>> + if (branch->work_tree && !strcmp(branch->work_tree, work_tree))
>> + record_checkout(old.name, "");
>> + record_checkout(new->name, work_tree);
>> + }
>> +
>
> Likewise for new->name, but also old.name which is only set when old.path
> is set and begins with "refs/heads/" and otherwise NULL.
I was more looking for feedback on the idea than the implementation, but
here's a better implementation. Still an RFC so no tests yet.
-- >8 --
Subject: [RFC/PATCH] Teach branch/checkout about workdirs
When using 'git new-workdir', there is no safety mechanism to prevent the
same branch from being checked out twice, nor to prevent a checked out
branch from being deleted.
Teach 'checkout' to record the workdir path using 'branch.<name>.checkout'
when switching branches. We can then easily check if a branch is already
checked out in another workdir before switching to that branch. Add a
similar check before deleting a branch.
Allow 'checkout -f' to force the checkout and issue a warning instead of
an error.
Guard this behavior behind 'core.recordCheckouts', which we will teach
'git new-workdir' to set in a followup commit.
Note: when switching away from a branch, we set 'branch.<name>.checkout'
to the empty string, instead of deleting it entirely, since git_config()
otherwise leaves behind an empty section which it does not re-use.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
builtin/branch.c | 10 ++++++++++
builtin/checkout.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
remote.c | 4 ++++
remote.h | 1 +
4 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index f49596f826..6ce1a5b133 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -182,6 +182,16 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
ret = 1;
continue;
}
+ if (kinds == REF_LOCAL_BRANCH) {
+ struct branch *branch = branch_get(bname.buf);
+ if (branch->work_tree && strlen(branch->work_tree)) {
+ error(_("Cannot delete the branch '%s' "
+ "which is currently checked out in '%s'"),
+ bname.buf, branch->work_tree);
+ ret = 1;
+ continue;
+ }
+ }
free(name);
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5e356a6c61..b3c658ffd4 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -33,6 +33,7 @@ struct checkout_opts {
int force_detach;
int writeout_stage;
int writeout_error;
+ int record_checkouts;
/* not set by parse_options */
int branch_exists;
@@ -508,6 +509,20 @@ static void detach_advice(const char *old_path, const char *new_name)
fprintf(stderr, fmt, new_name);
}
+static void record_checkout(const char *name, const char *new_work_tree)
+{
+ struct strbuf key = STRBUF_INIT;
+ strbuf_addf(&key, "branch.%s.checkout", name);
+ if (new_work_tree) { /* reserve name */
+ git_config_set(key.buf, new_work_tree);
+ } else { /* release name if we reserved it */
+ struct branch *branch = branch_get(name);
+ if (!strcmp(branch->work_tree, get_git_work_tree()))
+ git_config_set(key.buf, "");
+ }
+ strbuf_release(&key);
+}
+
static void update_refs_for_switch(struct checkout_opts *opts,
struct branch_info *old,
struct branch_info *new)
@@ -556,6 +571,8 @@ static void update_refs_for_switch(struct checkout_opts *opts,
detach_advice(old->path, new->name);
describe_detached_head(_("HEAD is now at"), new->commit);
}
+ if (opts->record_checkouts && old->name)
+ record_checkout(old->name, NULL);
} else if (new->path) { /* Switch branches. */
create_symref("HEAD", new->path, msg.buf);
if (!opts->quiet) {
@@ -580,6 +597,11 @@ static void update_refs_for_switch(struct checkout_opts *opts,
if (!file_exists(ref_file) && file_exists(log_file))
remove_path(log_file);
}
+ if (opts->record_checkouts) {
+ if (old->name)
+ record_checkout(old->name, NULL);
+ record_checkout(new->name, get_git_work_tree());
+ }
}
remove_branch_state();
strbuf_release(&msg);
@@ -709,6 +731,23 @@ static void orphaned_commit_warning(struct commit *commit)
for_each_ref(clear_commit_marks_from_one_ref, NULL);
}
+static void check_if_checked_out(struct checkout_opts *opts, const char *name)
+{
+ struct branch *branch;
+ if (!opts->record_checkouts)
+ return;
+ branch = branch_get(name);
+ if (branch->work_tree && strlen(branch->work_tree) &&
+ strcmp(branch->work_tree, get_git_work_tree())) {
+ if (opts->force)
+ warning(_("branch '%s' is currently checked out"
+ " in '%s'"), name, branch->work_tree);
+ else
+ die(_("branch '%s' is currently checked out"
+ " in '%s'"), name, branch->work_tree);
+ }
+}
+
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
{
int ret = 0;
@@ -732,6 +771,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
if (!new->commit)
die(_("You are on a branch yet to be born"));
parse_commit(new->commit);
+ } else if (opts->record_checkouts) {
+ check_if_checked_out(opts, new->name);
}
ret = merge_working_tree(opts, &old, new);
@@ -756,6 +797,10 @@ static int git_checkout_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "core.recordcheckouts")) {
+ struct checkout_opts *opts = cb;
+ opts->record_checkouts = git_config_bool(var, value);
+ }
if (!prefixcmp(var, "submodule."))
return parse_submodule_config_option(var, value);
diff --git a/remote.c b/remote.c
index b8ecfa5d95..2bc063dae8 100644
--- a/remote.c
+++ b/remote.c
@@ -364,6 +364,10 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!value)
return config_error_nonbool(key);
add_merge(branch, xstrdup(value));
+ } else if (!strcmp(subkey, ".checkout")) {
+ if (!value)
+ return config_error_nonbool(key);
+ branch->work_tree = xstrdup(value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 9a30a9dba6..4103ec7e31 100644
--- a/remote.h
+++ b/remote.h
@@ -126,6 +126,7 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec);
struct branch {
const char *name;
const char *refname;
+ const char *work_tree;
const char *remote_name;
struct remote *remote;
--
1.7.7.4.g39e02c
^ permalink raw reply related
* [BUG] git stash -k show the help message for diff-index
From: Matthieu Moy @ 2011-10-05 15:13 UTC (permalink / raw)
To: git
Everything is in the title. No time to bisect/fix this now, but:
$ git status
# On branch master
nothing to commit (working directory clean)
$ git stash -k
usage: git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
common diff options:
-z output diff-raw with lines terminated with NUL.
-p output patch format.
-u synonym for -p.
--patch-with-raw
output both a patch and the diff-raw format.
--stat show diffstat instead of patch.
--numstat show numeric diffstat instead of patch.
--patch-with-stat
output a patch and prepend its diffstat.
--name-only show only names of changed files.
--name-status show names and status of changed files.
--full-index show full object name on index lines.
--abbrev=<n> abbreviate object names in diff-tree header and diff-raw.
-R swap input file pairs.
-B detect complete rewrites.
-M detect renames.
-C detect copies.
--find-copies-harder
try unchanged files as candidate for copy detection.
-l<n> limit rename attempts up to <n> paths.
-O<file> reorder diffs according to the <file>.
-S<string> find filepair whose only one side contains the string.
--pickaxe-all
show all files diff when -S is used and hit is found.
-a --text treat all files as text.
usage: git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
common diff options:
-z output diff-raw with lines terminated with NUL.
-p output patch format.
-u synonym for -p.
--patch-with-raw
output both a patch and the diff-raw format.
--stat show diffstat instead of patch.
--numstat show numeric diffstat instead of patch.
--patch-with-stat
output a patch and prepend its diffstat.
--name-only show only names of changed files.
--name-status show names and status of changed files.
--full-index show full object name on index lines.
--abbrev=<n> abbreviate object names in diff-tree header and diff-raw.
-R swap input file pairs.
-B detect complete rewrites.
-M detect renames.
-C detect copies.
--find-copies-harder
try unchanged files as candidate for copy detection.
-l<n> limit rename attempts up to <n> paths.
-O<file> reorder diffs according to the <file>.
-S<string> find filepair whose only one side contains the string.
--pickaxe-all
show all files diff when -S is used and hit is found.
-a --text treat all files as text.
Saved working directory and index state WIP on master: 977c790 foo
HEAD is now at 977c790 foo
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* git-cherry-pick and git-commit --amend in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-05 14:52 UTC (permalink / raw)
To: git
Hi,
still with version 1.7.6.4, when I do a cherry-pick, that succeeded, I cannot do
a commit --amend after:
# git cherry-pick 3f78d1f210ff89af77f042ab7f4a8fee39feb1c9
[dev 1a04a23] drivers/net/usb/asix.c: Fix unaligned accesses
1 files changed, 33 insertions(+), 1 deletions(-)
# echo $?
0
# git commit --amend
fatal: You are in the middle of a cherry-pick -- cannot amend.
#
The same operations (with the same patch), with version 1.7.3.4 is ok.
Regards,
Nicolas
^ permalink raw reply
* git-cherry-pick and author field in version 1.7.6.4
From: Nicolas Dichtel @ 2011-10-05 14:51 UTC (permalink / raw)
To: git
Hi all,
in the last stable version (1.7.6.4), when I perform a git-cherry-pick, the
initial author of the patch is erased whith my name (it was not the case in
version 1.7.3.4 and prior). Is this behavior intended ? Is there an option to
keep the initial author of the patch?
Regards,
Nicolas
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-05 14:47 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4E8C481A.1070808@alum.mit.edu>
On 05/10/2011 14:05, Michael Haggerty wrote:
> On 10/04/2011 08:52 PM, Gioele Barabucci wrote:
>> With the newer v1.7.7 I get this, instead:
>>
>> .: show_in_prompt: unspecified
>>
>> I see in the release notes of 1.7.7-rc1 that `check-attr` has been
>> changed to allow relative paths to be specified. Maybe this error is
>> related to that change.
>
> Indeed, your use case is broken by
>
> f5114a40c0d0276ce6ff215a3dc51eb19da5b420
Wow, debug-by-changelog :)
> In fact the support for gitattributes using patterns involving "." was
> pretty spotty in v1.7.6 too. For example,
[...]
> It's not to hard to fix your particular use case. But for a real fix,
> we would need to decide what is the correct behavior in all of the lines
> above marked "?"; specifically, should "." match every subdirectory
> under a given directory, does it match only the directory containing the
> .gitattributes file, or is this construct illegal?
I do not know what the correct behavior should be, but here is my use case.
I use git to version almost all my $HOME dir. In addition to my usual
files there are also separate project repositories under $HOME. I enjoy
using a git-enabled prompt in those projects' dirs but not in my $HOME dir.
So I have this code somewhere in my `~/.bashrc`:
local show_status="$(git check-attr show_in_prompt -- .)"
local show_pattern='^\.: show_in_prompt: (.*)$'
# add the following line to .gitattributes
#
# /. show_in_prompt=no
local show_in_prompt='yes'
if [[ ${show_status} =~ ${show_pattern} ]]; then
show_in_prompt="${BASH_REMATCH[1]}"
fi
if [ "${show_in_prompt}" == 'no' ]; then
return
fi
As you see in my the line of this code, I exploit the fact that "."
refers to the root git dir, not to the current dir, to simplify the
code. Otherwise I would had to discover what is the path of the current
dir relative to its root git dir, something that I'd like to avoid as
this code runs every time the prompt is shown.
This is just my personal use case. On the other hand, the first time I
looked at check-attr I found it strange that paths were meant as
relative to the root git dir ("." in "/foo" = "/") and not expanded from
the current dir ("." in "/foo" = "/foo").
Bye,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: git commit -a reports untracked files after a clone
From: Joerg Rosenkranz @ 2011-10-05 14:26 UTC (permalink / raw)
To: git
In-Reply-To: <20110527181321.GB29119@sigill.intra.peff.net>
> On Fri, May 27, 2011 at 02:00:45PM -0400, Jeff King wrote:
> 1. We load the index, and for each entry, insert it into the index's
> name_hash. In addition, if ignorecase is turned on, we make an
> entry in the name_hash for the directory (e.g., "contrib/"), which
> uses the following code from 5102c61's hash_index_entry_directories:
Sorry for reactivating this old thread.
We are running in this problem too. The behavior is the same in msysgit and on
Linux. Your patch resolves that problem for us.
Is there any chance to drive this patch forward?
Thanks,
Joerg
^ permalink raw reply
* Re: [PATCHv3 1/5] enter_repo: do not modify input
From: Thomas Adam @ 2011-10-05 14:02 UTC (permalink / raw)
To: Phil Hord
Cc: git@vger.kernel.org, Phil Hord, Junio C Hamano, Erik Faye-Lund,
Nguyen Thai Ngoc Duy
In-Reply-To: <4E8C6233.8040906@cisco.com>
On 5 October 2011 14:57, Phil Hord <hordp@cisco.com> wrote:
> From: Erik Faye-Lund <kusmabite@gmail.com>
>
> entr_repo(..., 0) currently modifies the input to strip away
enter_repo???
-- Thomas Adam
^ permalink raw reply
* Re: [PATCHv3 1/5] enter_repo: do not modify input
From: Phil Hord @ 2011-10-05 13:57 UTC (permalink / raw)
To: git@vger.kernel.org, Phil Hord
Cc: Junio C Hamano, Erik Faye-Lund, Nguyen Thai Ngoc Duy
In-Reply-To: <4E8C5D4A.7060900@cisco.com>
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
---
Don't know why I keep screwing up this one commit. Here's another try with Word-Wrap in the Really, Really Off position.
diff --git a/cache.h b/cache.h
index 9994a3c..7eeb8cf 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err, va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..f3d96aa 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,17 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len);
+ used_path[len] = 0;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +319,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.505.ga09f6
^ permalink raw reply related
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Peter Krefting @ 2011-10-05 13:44 UTC (permalink / raw)
To: Git Mailing List
Cc: Ævar Arnfjörð Bjarmason, Jonathan Nieder,
Junio C Hamano, Ramkumar Ramachandra, Marcin Cieślak,
Sam Reed, Jan Engelhardt, Jan Krüger,
Nguyễn Thái Ngọc
In-Reply-To: <CACBZZX5uz5cdoWebYOY-Omu0drnQasJB-12DMZyZ_NX17jzhmg@mail.gmail.com>
Ævar Arnfjörð Bjarmason:
> While we could set up some "i18n maintainer" infrastructure why not just
> have people submit patches to the list like we do for every other file in
> git?
As mentioned, that infrastructure already exists in Translation Project -
http://translationproject.org/html/welcome.html
Submit the POT file at "string freeze" before a stable release, and pull the
translated PO files when the release happens. TP handles the rest.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCHv3 1/5] enter_repo: do not modify input
From: Phil Hord @ 2011-10-05 13:36 UTC (permalink / raw)
To: git@vger.kernel.org, Phil Hord
Cc: Junio C Hamano, Erik Faye-Lund, Nguyen Thai Ngoc Duy
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/cache.h b/cache.h
index 9994a3c..7eeb8cf 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..f3d96aa 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,17 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len);
+ used_path[len] = 0;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +319,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.505.ga09f6
^ permalink raw reply related
* [PATCHv3 5/5] Add test showing git-fetch groks gitfiles
From: Phil Hord @ 2011-10-05 13:35 UTC (permalink / raw)
To: git@vger.kernel.org, Phil Hord
Cc: Junio C Hamano, Erik Faye-Lund, Nguyen Thai Ngoc Duy
Add a test for two subtly different cases: 'git fetch path/.git'
and 'git fetch path' to confirm that transport recognizes both
paths as git repositories when using the gitfile mechanism.
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index e810314..87ee016 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -206,6 +206,20 @@ test_expect_success 'clone from .git file' '
git clone dst/.git dst2
'
+test_expect_success 'fetch from .git gitfile' '
+ (
+ cd dst2 &&
+ git fetch ../dst/.git
+ )
+'
+
+test_expect_success 'fetch from gitfile parent' '
+ (
+ cd dst2 &&
+ git fetch ../dst
+ )
+'
+
test_expect_success 'clone separate gitdir where target already exists' '
rm -rf dst &&
test_must_fail git clone --separate-git-dir realgitdir src dst
--
1.7.7.505.ga09f6
^ permalink raw reply related
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