* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
Aside, previous discussion -
http://thread.gmane.org/gmane.comp.version-control.git/150559
Sadly, it seems to have petered out, it looks to me like a case of
perfect being the enemy of the good. I'm really just trying to make it
good enough that we can move new-workdir out of contrib. It's a
valuable tool, we just need to remove some of its sharper edges.
j.
^ permalink raw reply
* Re: [PATCH 1/1] get_sha1_hex(): do not read past a NUL character
From: Thomas Rast @ 2011-10-05 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vaa9vulsw.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
> > Previously, get_sha1_hex() would read one character past the end of a
> > null-terminated string whose strlen was an even number less than 40.
> > Although the function correctly returned -1 in these cases, the extra
> > memory access might have been to uninitialized (or even, conceivably,
> > unallocated) memory.
> >
> > Add a check to avoid reading past the end of a string.
>
> Makes sense; thanks.
Has this fixed patch ever made it to pu? I'm still seeing the same
breakage in the automated valgrind runs.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Jay Soffian @ 2011-10-05 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vzkhf713u.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Careful. Git has survived without your patch series till now, as people
> learned to be careful when they use separate workdirs and avoid certain
> things, to the point that they are not necessarily aware that they are
> avoiding them (one good practice is to keep the HEADs of non-primary
> workdirs detached).
I think it's more likely the case that most people have avoided
new-workdir entirely.
Also, while I might recommend new-workdir to my coworkers with the
advice "don't checkout the same branch in multiple workdirs", never in
a million years would I say "use new-workdir, but make sure to only
use a detached HEAD in the workdirs." The latter would make their
actual HEADs explode. :-)
> For example, you checkout branch frotz in a workdir, and then in the
> primary repository that has nitfol branch checked out, you rename the
> frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz
> that no longer exist. Of course you can break the same way by doing a
> "update-ref -d refs/heads/frotz" from the primary repository.
>
> Because you forgot that the high level operation "branch renaming" needs
> to be aware of that "this branch is checked out elsewhere" information,
> you allowed it to break the workdir. If you hooked into lower level
> machinery that is shared, you wouldn't have caused this breakage.
> Similarly, if delete_ref() were taught about the new requirement, you
> would have covered both "branch -d" and "update-ref -d".
I did not forget, I just hadn't gotten there yet while this was still
an RFC/PATCH.
Another issue to resolve is what happens when the workdir or repo are
moved in the filesystem. And making prune aware of HEAD reflogs in the
alternate workdirs.
> I do not necessarily think that it is a good approach to forbid the same
> branch to be checked out in two different places, by the way. One reason
> people would want to keep multiple workdirs is so that while they are
> still working on a branch and are not yet at a good "stop point" to even
> make a temporary commit to get interrupted, they find it sometimes
> necessary to be able to build the tip of that same branch and even make a
> small in-working-tree fixes (which later will be carried back to the
> primary branch). The problem arises only when one of the repositories try
> to update or delete the branch while it is checked out in another working
> tree.
That is not at all my experience of how workdirs are used.
> Can this series be extended/reworked so that:
>
> - Each branch has multi-value configuration record to note the workdirs
> that it is checked out;
This is a good idea in any case for when "checkout --force" is used
(see below), so that we can find all the workdirs for other operations
that may need to.
> - Error out (or warn if forced) upon any attempt to update the tip of a
> branch that is checked out in more than one place; and
I think that's a worse user experience. "Sorry, can't commit your
changes because you've checked out this branch elsewhere." Now the
user's choices are:
1. commit --force (and thus confusing the other workdirs)
2. checkout -b new_branch && commit
Both of which I think are worse than preventing the checkout in the first place.
> - Similarly for renaming or deleting a branch that is checked out in more
> than one place.
Yep.
j.
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Junio C Hamano @ 2011-10-05 18:35 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: Michael Haggerty, git
In-Reply-To: <4E8C9A35.5030504@svario.it>
Gioele Barabucci <gioele@svario.it> writes:
> On 05/10/2011 19:38, Junio C Hamano wrote:
>>> In fact the support for gitattributes using patterns involving "." was
>>> pretty spotty in v1.7.6 too. For example,
>>
>> 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.
>
> What if I do not want to say things about the "content" of the
> directory but about the directory itself? This is exactly my case.
Oh, that is totally different. We do not store directories, and they do
not have attributes, period.
^ permalink raw reply
* Re: Git Bug report
From: Federico Lucifredi @ 2011-10-05 18:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4E8BF519.8090509@viscovery.net>
On Wed, 2011-10-05 at 08:11 +0200, Johannes Sixt wrote:
> >> 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.
>
> And the correct error message is...?
".git: permission denied" -- no need to be fatal (there could
be ../.git, etc - fatal comes only if those don't exist).
It could fail silently if one of the parents exists, but in the fatal
scenario, I should be told that it was by permission denied. Currently,
I am told there is no git repo where I know there to be one, which means
"what happened to my repo" is the next question in the user's head.
"it's there but it is broke" is the subtext one gets from this error. it
should be "it is there, I cannot get to it".
> >> drwx------ 8 root root 4096 2011-10-03 16:53 .git
>
> Assuming that you expected something like this:
>
> fatal: .git: permission denied
>
> it is hard to argue that a directory that happens to be named .git, but
> was sealed by its owner should be assumed to be a git repository, albeit
> one that we do not have access to. "Not a git repository" is an equally
> justifyable error message, IMHO.
An error message should help resolve the error in question, not grade
the user's smarts. Here I as a user had an expectation that there was a
git repository for /etc ("I set up one!") and figured the permission
issue with my own wits (well, I did not need to because it was /etc, but
in the general perm-denied case I would have had to), by looking at the
dir because the message gave me no useful information on the cause of
the problem.
Thanks -Federico
--
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C
^ permalink raw reply
* Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
From: Junio C Hamano @ 2011-10-05 18:19 UTC (permalink / raw)
To: Jay Soffian; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <CAG+J_Dz-GXvRbYUXSoyfyHfOO-_BszcOza9x=ysHhmL5YBW-Jw@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Git has survived w/o needing to lock branches till now.
Careful. Git has survived without your patch series till now, as people
learned to be careful when they use separate workdirs and avoid certain
things, to the point that they are not necessarily aware that they are
avoiding them (one good practice is to keep the HEADs of non-primary
workdirs detached).
Does that mean what your patch aims to do is unnecessary? I think not.
> What are these
> use cases we cannot already think of today?
What is important is that we should have learned by now that the "gotchas"
live where we do not immediately see. "Can you tell me what you are missing?"
is a senseless thing to ask.
>> 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.
There are pros and cons between hooking at lower level vs higher
level. The advantage of hooking at higher level is you do not risk
breaking low-level operations, but that directly results in allowing the
same low level operations that are unaware of the new requirement higher
level added break it. It also allows other high level operations you
forgot to teach the new requirement break it.
For example, you checkout branch frotz in a workdir, and then in the
primary repository that has nitfol branch checked out, you rename the
frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz
that no longer exist. Of course you can break the same way by doing a
"update-ref -d refs/heads/frotz" from the primary repository.
Because you forgot that the high level operation "branch renaming" needs
to be aware of that "this branch is checked out elsewhere" information,
you allowed it to break the workdir. If you hooked into lower level
machinery that is shared, you wouldn't have caused this breakage.
Similarly, if delete_ref() were taught about the new requirement, you
would have covered both "branch -d" and "update-ref -d".
I do not necessarily think that it is a good approach to forbid the same
branch to be checked out in two different places, by the way. One reason
people would want to keep multiple workdirs is so that while they are
still working on a branch and are not yet at a good "stop point" to even
make a temporary commit to get interrupted, they find it sometimes
necessary to be able to build the tip of that same branch and even make a
small in-working-tree fixes (which later will be carried back to the
primary branch). The problem arises only when one of the repositories try
to update or delete the branch while it is checked out in another working
tree.
Can this series be extended/reworked so that:
- Each branch has multi-value configuration record to note the workdirs
that it is checked out;
- Error out (or warn if forced) upon any attempt to update the tip of a
branch that is checked out in more than one place; and
- Similarly for renaming or deleting a branch that is checked out in more
than one place.
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-05 18:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <20111005175536.GB22962@sigill.intra.peff.net>
On Wed, Oct 05, 2011 at 01:55:36PM -0400, Jeff King wrote:
> On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote:
>
> > We seem to mean something different:
> >
> > git config --get remote.bitbucket.pushurl
> > https://grubix@bitbucket.org/grubix/git.git
> > SSH_ASKPASS= git push -n bitbucket
> > Username for 'bitbucket.org':
> >
> > I mean that git should not need to ask for the username here.
>
> No, we are in agreement about the intended behavior. I think you are
> seeing a bug. What version of git produced it?
>
> With my http-auth series, I get:
>
> $ git push https://github.com/peff/git.git
> Username for 'github.com':
>
> $ git push https://peff@github.com/peff/git.git
> Password for 'github.com':
>
> Using v1.7.7 produces similar results.
Hrm. I do get this, with the same version of git:
$ git config remote.foo.url https://github.com/peff/git.git
$ git push foo
Username for 'github.com':
$ git config remote.foo.url https://peff@github.com/peff/git.git
$ git push foo
Password for 'github.com':
So far so good. Now how about this:
$ git config remote.foo.url https://github.com/peff/git.git
$ git config remote.foo.pushurl https://peff@github.com/peff/git.git
$ git push foo
Username for 'github.com':
So I think the problem is with pushurl, not with the auth code. Oddly,
though, running GIT_TRACE reveals:
$ GIT_TRACE=1 git push foo
trace: built-in: git 'push' 'foo'
trace: run_command: 'git-remote-https' 'foo' 'https://peff@github.com/peff/git.git'
which is the right URL. So it's almost as if we are throwing away the
passed URL in favor of the configuration, and then looking up the
configuration wrong. I'm about to go get on a plane, so I don't have
more time to look at it now, but I suspect it's something simple and
stupid.
-Peff
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-05 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vd3eb8hkb.fsf@alter.siamese.dyndns.org>
On 05/10/2011 19:38, Junio C Hamano wrote:
>> In fact the support for gitattributes using patterns involving "." was
>> pretty spotty in v1.7.6 too. For example,
>
> 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.
What if I do not want to say things about the "content" of the directory
but about the directory itself? This is exactly my case.
> 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.
Actually what I have in my `~/.gitattributes` is
/. show_in_prompt=no
Anyway, I see a conflict between
> - A leading slash matches the beginning of the pathname.
> For example, "/{asterisk}.c" matches "cat-file.c" but not
> "mozilla-sha1/sha1.c".
and
> - If the pattern is a single dot and nothing else, it matches everything
> in the current directory.
in the first case `.` is treated as a "glob dot", while in the second
case it is treated as a "regexp dot". I would find this confusing.
Patterns can match directories using `/foo`. Why don't you just say that
`.` is equivalent to `./` and `/foo/.` is equivalent to `/foo`?
> 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.
In the case of `.gitignore`, `/foo/.` and `/foo/` would have the same
effect and they look sane to me.
> 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?
I would be surprised as I expect `.` to be a "glob dot". But maybe it is
just me and my prejudices :)
Bye,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Jeff King @ 2011-10-05 17:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4E8B5553.2080706@drmicha.warpmail.net>
On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote:
> We seem to mean something different:
>
> git config --get remote.bitbucket.pushurl
> https://grubix@bitbucket.org/grubix/git.git
> SSH_ASKPASS= git push -n bitbucket
> Username for 'bitbucket.org':
>
> I mean that git should not need to ask for the username here.
No, we are in agreement about the intended behavior. I think you are
seeing a bug. What version of git produced it?
With my http-auth series, I get:
$ git push https://github.com/peff/git.git
Username for 'github.com':
$ git push https://peff@github.com/peff/git.git
Password for 'github.com':
Using v1.7.7 produces similar results.
-Peff
^ permalink raw reply
* 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
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