* Re: [PATCH] add -e: ignore dirty submodules
From: Johannes Schindelin @ 2012-02-07 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa4v42fi.fsf@alter.siamese.dyndns.org>
Dear Junio C Hamano,
On Mon, 6 Feb 2012, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > We cannot add untracked/modified files in submodules anyway.
The purpose of "add -e" is to stage changes. It does so by presenting a
diff which the user can edit (and applying it after recounting the numbers
in the hunk headers).
If the diff does not apply, it does not make sense to present it to the
user.
Offering to add changes represented by a diff like
diff --git <blub>
<header>
-deadbeef...
+deadbeef...-dirty
does not make sense.
Even a diff like
diff --git <blah>
<header>
-deadbeef...
-coffeebabe...-dirty
would be refused by git-apply.
Indeed, due to the design of the submodules, it is impossible to stage
dirty files in a submodule and a supercommit at the same time. Oh, and this
discussion is not the place to wish for a feature like that, just in case
you want to ask me to implement that in order to be allowed to have my puny
little patch applied. (I guess this is the reason why I waited so long
before I dared to submit the patch to the mailing list.)
Now, due to these concerns, even stripping out the -dirty part can lead to
a comically non-sensical diff like
diff --git <blergh>
<header>
-deadbeef...
+deadbeef...
So keeping the diff generation as-is but preparing the patch by munching
away the -dirty suffix would not fix the problem.
Also, it would be wrong to assume that the user asked to get a status
update. git add -e != git status. If the user wanted to know what changes
are in the worktree, including the worktrees of the submodules, but only
those that have been checked out, git status would be the command to call
(even if it was touted as a git commit --dry-run once upon a time, which
is kind of wrong, see above, you cannot commit the untracked or dirty
files in a submodule, yet git status shows them).
So: showing the fact that a submodule has untracked or dirty files in the
patch that the user wants to edit with git add -e is wrong, wrong, wrong.
The only submodule-related thing we should ever present to the user who
called git add -e is a diff like
diff --git <narf>
<header>
-deadcad...
+beda551ed...
because that is a stageable change.
Alas, salvation is nigh! Yes, just a little line which asks for the level
"dirty" (which implies "untracked", as detailed by diff-options.txt, uhm,
sorry, I was asked to be precise, Documentation/diff-options.txt) fixes
that!
With this flag, there are no more "-dirty" lines in the submodule diffs.
None! Only diffs between different submodule commits are shown, and even
if the worktree of the submodule is dirty, or has untracked files, the
-dirty suffix is omitted. Just what you need for git-apply to work! Yay!
As a plus, it makes the diff generation faster because what cannot be
staged anyway is not even discovered! Super-yay!
I actually enjoyed writing this text so much, may I respectfully ask to
include it verbatim in the commit message?
Thank you very much,
Johannes Schindelin
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-07 7:57 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <CACsJy8CaFhyzgh6N4ov49Tf0mA8qV5uQESFP2u8U7AduOd59PA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2012/2/7 Junio C Hamano <gitster@pobox.com>:
>> Unless you are doing "commit -a" or "commit pathspec", you are responsible
>> for adding all contents you want to have in the commit before you run the
>> "git commit" command (and for the purpose of this statement, "add -N" to
>> tell Git to keey an eye on a path does _not_ add contents). A change to
>> the file in the working tree that is left unadded is what you decided to
>> deliberately leave out of the commit, be it a change to a path already in
>> HEAD, or a path marked with "add -N". Forgetting to add modified file and
>> forgetting to add a file you earlier used "add -N" amount to the same kind
>> of risk, and "git status" is the way to make sure your partial commit has
>> exactly what you want (if you are not worried about partial commit, you
>> would be doing "commit -a", so the "safety" is a moot point).
>
> We need something in the commit message so that 5 years from now, when
> someone raises the issue again, (s)he does not have to search the mail
> archive. May I steal the above paragraph, maybe rephrase a little bit,
> for commit message?
Surely, and thanks.
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Michael Haggerty @ 2012-02-07 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Andrew Ardill, git
In-Reply-To: <7vpqdr7rn0.fsf@alter.siamese.dyndns.org>
On 02/06/2012 07:17 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> Probably I am slower than my usual slow self this morning. Does Michael's
> approach go like this:
>
> git init project
> cd project
> import import import
> git branch -m vendor
> git checkout -b master
>
> to fork from third-party codebase?
I'm not really forking the third-party code; I'm just importing a
snapshot to a particular subdirectory of my own project. I wanted to do
something like:
git init project
cd project
git checkout -b vendor
import import import commit (into subdirectory "foo")
git checkout --orphan master
git clean -fxd
hack commit hack commit
# Then when the vendor stuff is logically needed in master:
git merge vendor
With the option to import later snapshots of the third-party code to the
"vendor" branch then re-merge it to master.
> Care to come up with a patch to Documentation/git-checkout.txt? The
> description there strongly implies that <start point> is an existing
> commit. Not much is said about what the lack of <start point> mean when
> it describes "checkout -b", and a standalone description of <start point>
> says "The name of a comit at which to start... Defaults to HEAD". These
> need to be loosened and described in terms of the closer-to-the-user "at
> my current state".
I'll work on it as soon as I have time.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] add -e: ignore dirty submodules
From: Junio C Hamano @ 2012-02-07 8:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1202070124020.4897@bonsai2>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Offering to add changes represented by a diff like
>
> diff --git <blub>
> <header>
> -deadbeef...
> +deadbeef...-dirty
>
> does not make sense.
Now you are being much clearer. If you had the above from the beginning,
I wouldn't have had to ask.
So after all, this is a noise reduction patch, and I think that it is a
good change.
> Even a diff like
>
> diff --git <blah>
> <header>
> -deadbeef...
> -coffeebabe...-dirty
>
> would be refused by git-apply.
That would be refused, but if you replace '-coffeebabe' with '+coffeebabe',
which is what you would get from "git diff" without ignore-dirty-submodule,
I think it would be accepted by "git apply" just fine.
Have you tried it?
> I actually enjoyed writing this text so much, may I respectfully ask to
> include it verbatim in the commit message?
With mostly irrelevant mumblings and all? Of course not.
I was asking what you meant to achieve with the patch, because you did not
even include relevant bits of information.
But now I think I learned what you meant by this patch, so let me try to
see if I understood it correctly by rephrasing it.
Like this?
-- >8 --
Subject: add -e: do not show difference in a submodule that is merely dirty
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue, 7 Feb 2012 05:05:48 +0100 (CET)
When the HEAD of the submodule matches what is recorded in the index of
the superproject, and it has local changes or untracked files, the patch
offered by "git add -e" for editing shows a diff like this:
diff --git a/submodule b/submodule
<header>
-deadbeef...
+deadbeef...-dirty
Because applying such a patch has no effect to the index, this is a
useless noise. Generate the patch with IGNORE_DIRTY_SUBMODULES flag to
prevent such a change from getting reported.
This patch also loses the "-dirty" suffix from the output when the HEAD of
the submodule is different from what is in the index of the superproject.
As such dirtiness expressed by the suffix does not affect the result of
the patch application at all, there is no information lost if we remove
it. The user could still run "git status" before "git add -e" if s/he
cares about the dirtiness.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin/add.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 1c42900..b79336d 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -280,6 +280,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix)
argc = setup_revisions(argc, argv, &rev, NULL);
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
+ DIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES);
out = open(file, O_CREAT | O_WRONLY, 0644);
if (out < 0)
die (_("Could not open '%s' for writing."), file);
^ permalink raw reply related
* Re: [PATCHv2] tag: add --points-at list option
From: Junio C Hamano @ 2012-02-07 8:35 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, peff, jasampler
In-Reply-To: <1328598076-7773-2-git-send-email-tmgrennan@gmail.com>
Tom Grennan <tmgrennan@gmail.com> writes:
> +struct points_at {
> + struct points_at *next;
> + unsigned char *sha1;
> +};
struct points_at {
struct points_at *next;
unsigned char sha1[20];
};
would save you from having to allocate and free always in pairs, no?
> +static void free_points_at (struct points_at *points_at)
Please lose the SP before (.
> + if (type != OBJ_TAG
> + || (tag = lookup_tag(sha1), !tag)
> + || parse_tag_buffer(tag, buf, size) < 0) {
Even though I personally prefer to cascade a long expression like this, so
that you see a parse tree when you tilt your head 90-degrees to the left,
I think the prevalent style in Git codebase is
if (A-long-long-expression ||
B-long-long-expression ||
C-long-long-expression) {
Also we try to avoid assignment in the conditional.
> @@ -432,6 +500,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
> PARSE_OPT_LASTARG_DEFAULT,
> parse_opt_with_commit, (intptr_t)"HEAD",
> },
> + {
> + OPTION_CALLBACK, 0, "points-at", &points_at, "object",
> + "print only annotated|signed tags of the object",
> + PARSE_OPT_LASTARG_DEFAULT,
> + parse_opt_points_at, (intptr_t)NULL,
> + },
If you are going to reject NULL anyway, do you still need to mark this as
lastarg-default?
Looking for example in parse-options.h, I found this:
#define OPT_STRING_LIST(s, l, v, a, h) \
{ OPTION_CALLBACK, (s), (l), (v), (a), \
(h), 0, &parse_opt_string_list }
which is used by "git clone" to mark its -c option.
Running "git clone -c" gives me
error: switch 'c' requires a value
without any extra code in the caller of parse_options().
Other than that, looks cleanly done.
Thanks. I'll take another look after I wake up in the morning.
^ permalink raw reply
* Re: [PATCH 3/6] Stop producing index version 2
From: Nguyen Thai Ngoc Duy @ 2012-02-07 8:51 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, Thomas Rast, Joshua Redstone
In-Reply-To: <CACsJy8Ayqea75xeFKJNm6iT7GSUGDEfvZD17uEv7ihr4SS2LMg@mail.gmail.com>
On Tue, Feb 7, 2012 at 11:50 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> Version 3 was a mistake because of the variable length record sizes.
>> Saving 2 bytes on some records that don't use the extended flags makes
>> the index file *MUCH* harder to parse. So much so that we should take
>> version 3 and kill it, not encourage it as the default!
>
> Probably too late for that, but it's good to know there are strong
> user base for v2.
OK probably not too late. We cannot kill it, but we could deprecate
it. We can introduce a mandatory extension to store extra flags. The
extension is basically an array of
struct ce_extended_flags {
int ce_index; /* points to istate->cache[ce_index] */
unsigned long flags;
};
On reading the extension, extra flags is applied back in mem, the
extension is created again when new index is written. There are only
two users of index v3: skip-worktree and intent-to-add bits, which are
not used often, I think. Still want to kill it?
Switching from sha-1 to crc32 could be done the same way (i.e. new
mandatory extension _at the end_ that contains crc32 checksum and skip
sha-1 check on reading if it's all zero) if we agree to move to crc32.
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: Emanuele Zattin @ 2012-02-07 8:58 UTC (permalink / raw)
To: git
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone <at> fb.com> writes:
>
> Hi Git folks,
>
Hello everybody!
I would just like to contribute a small set of blog posts
about this issue and a possible solution.
Sorry for the tone in which I wrote those posts,
but I think there are some valid points in there.
https://gist.github.com/1758346
BR,
Emanuele Zattin
^ permalink raw reply
* Re: User authentication in GIT
From: Jakub Narebski @ 2012-02-07 9:12 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328595129258-7261349.post@n2.nabble.com>
supadhyay <supadhyay@imany.com> writes:
> I want to migrate my existing version control system (CVS) into GIT. The
> first question which comes to me is in CVS we have user authentication like
> username and their password while in GIT there is SSH authentication.
Do you use _unencrypted_ pserver, or tunelling over SSH (with CVS_RSH)?
> Can any one suggest me what is the optimal way to manage the users in GIT?
> Does all users having username, passoword and SSH key? or there is no users
> credential but only SSH authentication? if I have 1000 users in old system
> CVS then do I need to create a key for all 1000 users in GIT? or etc.
First, Git supports unauthenticated anonymous fetching via custom
git:// protocol and via HTTP. If you only need read-only access to
repository, it would be enough. No account or SSH key necessary.
Second, Git uses SSH for authenthication instead of hand-rolling its
own security system, badly. You don't need to create 1000 shell
accounts for SSH access: use tool like gitolite to manage git
repositories, which uses public-key infrastructure without need to
generate 1000 accounts. You would still need for each user to
generate their own SSH key.
See gitolite documentation for more detail (older gitosis tool is no
longer maintained, as far as I know).
HTH
--
Jakub Narebski
^ permalink raw reply
* Merging only a subdirectory from one branch to the other
From: Howard Miller @ 2012-02-07 9:38 UTC (permalink / raw)
To: git
Hi,
I've been Googling for this one and am, mostly, more confused than
when I started so if you could humor me for a moment.
I have a branch with a particular subdirectory tree. The tree has a
lot of history. However, all the history for that subdirectory is
exclusive to it (no commits changed anything outside it). I now need
to merge that subdirectory into a completely different branch without
loosing any history. I think git-read-tree might have something to do
with it but I don't understand the help file at all. Any help
appreciated.
Cheers....
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: David Aguilar @ 2012-02-07 10:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120207051719.GA11598@sigill.intra.peff.net>
On Mon, Feb 6, 2012 at 9:17 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 06, 2012 at 09:01:21PM -0800, David Aguilar wrote:
>
>> I have a questions about this. Let's say I have ~/foo1.gitconfig:
>>
>> [foo]
>> bar = 1
>>
>> ...and ~/.gitconfig (I forgot the syntax):
>>
>> [foo]
>> bar = 0
>>
>> #include "~/foo1.gitconfig"
>>
>>
>> Does that mean that:
>>
>> $ git config -f ~/.gitconfig foo.bar
>>
>> ...prints 0 and not 1?
>
> Yes, though the syntax is:
>
> [include]
> path = foo1.gitconfig
>
> (it doesn't respect tilde-expansion, but it probably should). Note that
> the syntax was specifically selected for backwards compatibility, and to
> allow manipulation with existing tools.
>
>> I can see cases where this would be undesirable behavior.
>>
>> For example, an application that uses "git config -z --list -f
>> ~/.gitconfig" might expect that the result encompasses all of the
>> user-specific config bits.
>
> The problem is that an application might also expect it _not_ to happen
> (e.g., if the application is really interested in knowing what's in
> ~/.gitconfig). Because includes aren't respected now, the safe default
> seems to be not to have includes (i.e., don't change behavior for this
> case).
>
> A bigger question for me is: if you are interested in getting an answer
> from anywhere, why are you restricting with "-f"? IOW, is this a
> real-world problem, or a hypothetical one? And if real-world, what is
> the actual use case?
It's a real-world problem. I haven't had to change the code in a
while which is why this thread caught my eye ;-)
I won't claim it's the best solution, but this has worked extremely
well in practice:
https://github.com/git-cola/git-cola/blob/master/cola/gitcfg.py
Here's the problem. I need to know which config items are "user"
config (~/.gitconfig), which are "repo" config (.git/config), and
which are "system" config (/etc/gitconfig).
I also need to avoid calling "git config" too many times so I query
these files once and cache it all in memory. We need only stat()
these files to know whether to redo the "git config" call.
Figuring out the repo config is tricky. You can't just say "git
config --list" because that includes the user config stuff in
~/.gitconfig.
Figuring out the user config is easy because you can say "git config
--global --list". This is inconsistent with the behavior for "git
config --list" because it does not include the --system config, which
one would expect given the overlay semantics.
Figuring out the system config can be done with --system. That works fine.
The generic interface for getting a concise listing of values from
these sources is to use "git config -f" on ~/.gitconfig, .git/config,
and $(prefix)/etc/gitconfig.
git config --global and git config --system are both consistent in
that they return just the information relevant to them. Is --global
just a shortcut for "-f ~/.gitconfig"? If yes, then does that mean
"git config --global" will not honor includes? If it is not a
shortcut, does that mean that "git config --global" and "git config -f
~/.gitconfig" are not really the same thing? The documentation does
lead one to believe that they should be equivalent...
The takeaway is that querying these files provides a convenient way to
access the effective configuration values for the system, user, and
repo.
>> I do know where I would use an `--include` flag (if following includes
>> were not the default behavior when using '-f'), though, and that's why
>> I'm asking. The problem with not having it be the default means we
>> have to use a flag. This makes it harder to support multiple versions
>> of git.
>
> Yes, that's a general problem of adding new command-line options to turn
> features off or on. We could add an environment variable to control this
> feature. But I'd really like to hear the compelling use case first
> (i.e., both why it cannot simply be spelled "git config -z --list", and
> why not following includes is not OK).
Hopefully my explanation conveys why "git config -z --list" is insufficient.
Basically, I've been relying on the fact that querying each of these
files gives me exactly what users have effectively configured.
Pushing knowledge of includes onto the application is less fun.
Applications would either have to understand the [include] path = ...
construct and do something with it themselves or they'd have to check
the git version at runtime.
I would rather do without the runtime version check and have
everything "keep working".
So let's explore why I think it should follow includes. Here are a
few reasons...
When the file format supports including other files then the most
logical thing for it to do is to follow those includes, no? I know,
this is a tautology ;-). I'll try again.
From a naive user's POV --
I am asking "git config" to evaluate this file. I don't care what's
inside of it; it's a black box to me. All I know is that I get config
values out the other side. Sometimes git respects the included files.
Sometimes it does not (when using -f).
^^^^^^^^^
I think this subtle difference in behavior is best avoided.
Here's another. The naive user will do: `git config --list -f file`.
They will then edit that file to add an include statement. They will
then run `git config --list -f file` again and be confused as to why
their included configuration is not honored.
Right now these two are synonymous: "git config --system --list" and
"git config -f $(prefix)/etc/gitconfig --list". Having one form honor
includes and not the other is inconsistent.
What if we frame this the other way around -- when would we not want
it to follow includes? I can imagine someone writing a "git config"
editing program, but I think that use case is rare (and they haven't
spoken up, either ;-).
Well.. okay. My use case is rare too! The dumb "cache the values
behind a stat() call" thing has worked really well in practice so I've
been happy with it so far. It's dumb, and it won't notice when
included files change, but I really don't care because it solves the
99% case.
I'd be happy to rewrite it using another approach. The
overlay-semantics inconsistency is what led me to using the generic
"-f" interface. Performance issues led me to use a stat cache. Using
each file's stat info as the cache key mapped nicely onto the generic
approach of using "-f".
Rewriting it (for me) would mean using --global and --system and
probably not caring so much about the distinction of repo vs. user
configuration (or rather, deal with the fact that `git config --list`
returns both the user config and the repo config). At that point I
might as well just write (reuse) a proper .gitconfig parser, but
what's the fun in that when "git config" is so nice and easy to parse?
;-)
--
David
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Jakub Narebski @ 2012-02-07 10:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20120207070628.GA24698@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> I have a tree where I checked out a remote, without
> creating a local branch, this detaches the HEAD:
> # git branch
> * (no branch)
> master
> #git log|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
> #git log master..HEAD|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
>
>
> Now if I try to clone it:
> #git clone -n lab:/home/mst/scm/linux
> Initialized empty Git repository in /home/mst/scm/linux/.git/
> remote: Counting objects: 1693446, done.
> remote: Compressing objects: 100% (277054/277054), done.
> Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> done.
> remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> Resolving deltas: 100% (1414353/1414353), done.
> error: Trying to write ref HEAD with nonexistant object
> cec64082f689f949a397cb9b39423dc41545fa0e
> fatal: Cannot update the ref 'HEAD'.
>
> Looks like a bug, doesn't it?
Which git version? IIRC there was some bugfix recently in that
area...
--
Jakub Narebski
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Michael S. Tsirkin @ 2012-02-07 10:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m362fjklb7.fsf@localhost.localdomain>
On Tue, Feb 07, 2012 at 02:08:33AM -0800, Jakub Narebski wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > I have a tree where I checked out a remote, without
> > creating a local branch, this detaches the HEAD:
> > # git branch
> > * (no branch)
> > master
> > #git log|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> > #git log master..HEAD|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> >
> >
> > Now if I try to clone it:
> > #git clone -n lab:/home/mst/scm/linux
> > Initialized empty Git repository in /home/mst/scm/linux/.git/
> > remote: Counting objects: 1693446, done.
> > remote: Compressing objects: 100% (277054/277054), done.
> > Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> > done.
> > remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> > Resolving deltas: 100% (1414353/1414353), done.
> > error: Trying to write ref HEAD with nonexistant object
> > cec64082f689f949a397cb9b39423dc41545fa0e
> > fatal: Cannot update the ref 'HEAD'.
> >
> > Looks like a bug, doesn't it?
>
> Which git version? IIRC there was some bugfix recently in that
> area...
Sorry, forgot to mention that. It's pretty recent:
$ git --version
git version 1.7.9.111.gf3fb0
> --
> Jakub Narebski
^ permalink raw reply
* Re: User authentication in GIT
From: supadhyay @ 2012-02-07 11:47 UTC (permalink / raw)
To: git
In-Reply-To: <1328595129258-7261349.post@n2.nabble.com>
Hi Robin and Jakub,
Thanks for your reply. But I am still not getting what exactly I need to
perform on GIT server. Please find my reply on your suggestion below:
Robin:
All users must have their own SSH key. You do not create keys for them.
My rely: can you please give some more idea about how it works.. I am not
getting this or if you can provide any link for this to understand.
Jakub:
My reply: existing version control system used pserver protocol.
You would still need for each user to generate their own SSH key.
My reply: Do I need to store all end users sSH key in .ssh/authorized_keys
file on GIT server?
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7262113.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Git documentation at kernel.org
From: Petr Onderka @ 2012-02-07 12:28 UTC (permalink / raw)
To: git
Hi,
since the hacking of kernel.org, the online version of git
documentation [1] is not available. I realize that I can use local
version of the documentation and there is also at least one mirror
[2]. But I think it's very useful to have an "official" version of the
documentation online. And, more importantly, there is now lots of dead
links all over the Internet to the kernel.org version of the
documentation.
Can someone with the ability to do so restore the documentation at the
old location?
Thanks.
Petr Onderka
[1]: http://www.kernel.org/pub/software/scm/git/docs/git.html
[2]: http://schacon.github.com/git/git.html
^ permalink raw reply
* Re: User authentication in GIT
From: compufreak @ 2012-02-07 12:31 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328615262741-7262113.post@n2.nabble.com>
Inline respon
On Tue, Feb 7, 2012 at 12:47 PM, supadhyay <supadhyay@imany.com> wrote:
> Hi Robin and Jakub,
> ...
> Robin:
> All users must have their own SSH key. You do not create keys for them.
> My rely: can you please give some more idea about how it works.. I am not
> getting this or if you can provide any link for this to understand.
SSH authentication can use private/public keys. The user generates a
keypair on their computer and gives you their public key, the private
key stays on their computer.
>
> Jakub:
> My reply: existing version control system used pserver protocol.
>
> You would still need for each user to generate their own SSH key.
> My reply: Do I need to store all end users sSH key in .ssh/authorized_keys
> file on GIT server?
If you were to do it manually, yes. But if you use gitolite [1], then
you add them to another git repository which handles everything for
you.
> --
> View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7262113.html
> Sent from the git mailing list archive at Nabble.com.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[1]: https://github.com/sitaramc/gitolite
^ permalink raw reply
* Re: User authentication in GIT
From: Johan Herland @ 2012-02-07 12:32 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328615262741-7262113.post@n2.nabble.com>
On Tue, Feb 7, 2012 at 12:47, supadhyay <supadhyay@imany.com> wrote:
> Hi Robin and Jakub,
>
> Thanks for your reply. But I am still not getting what exactly I need to
> perform on GIT server. Please find my reply on your suggestion below:
>
>
> Robin:
> All users must have their own SSH key. You do not create keys for them.
> My rely: can you please give some more idea about how it works.. I am not
> getting this or if you can provide any link for this to understand.
- Each user generates their own ssh key pair on their own workstation
(in openssh, the command for generating a new key is called
'ssh-keygen')
- Each user then sends their public key to you (using email or
whatever communication form is easiest for you).
- You then load the keys into gitolite (by copying them into your
local clone of the gitolite-admin repo, committing, and pushing to the
gitolite-admin repo to the server).
More details here: http://sitaramc.github.com/gitolite/add.html (and
in associated documentation)
> Jakub:
> My reply: existing version control system used pserver protocol.
>
> You would still need for each user to generate their own SSH key.
> My reply: Do I need to store all end users sSH key in .ssh/authorized_keys
> file on GIT server?
No. You load them into gitolite (as described above, and in gitolite's
documentation), and then gitolite takes care of managing them.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH v2 1/4] cache-tree: update API to take abitrary flags
From: Nguyễn Thái Ngọc Duy @ 2012-02-07 12:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jonathan Nieder,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1328618804-31796-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/commit.c | 4 ++--
cache-tree.c | 27 ++++++++++++---------------
cache-tree.h | 4 +++-
merge-recursive.c | 2 +-
test-dump-cache-tree.c | 2 +-
5 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index eba1377..bf42bb3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -400,7 +400,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
refresh_cache_or_die(refresh_flags);
- update_main_cache_tree(1);
+ update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die(_("unable to write new_index file"));
@@ -421,7 +421,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
if (active_cache_changed) {
- update_main_cache_tree(1);
+ update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die(_("unable to write new_index file"));
diff --git a/cache-tree.c b/cache-tree.c
index 8de3959..16355d6 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -150,9 +150,10 @@ void cache_tree_invalidate_path(struct cache_tree *it, const char *path)
}
static int verify_cache(struct cache_entry **cache,
- int entries, int silent)
+ int entries, int flags)
{
int i, funny;
+ int silent = flags & WRITE_TREE_SILENT;
/* Verify that the tree is merged */
funny = 0;
@@ -241,10 +242,11 @@ static int update_one(struct cache_tree *it,
int entries,
const char *base,
int baselen,
- int missing_ok,
- int dryrun)
+ int flags)
{
struct strbuf buffer;
+ int missing_ok = flags & WRITE_TREE_MISSING_OK;
+ int dryrun = flags & WRITE_TREE_DRY_RUN;
int i;
if (0 <= it->entry_count && has_sha1_file(it->sha1))
@@ -288,8 +290,7 @@ static int update_one(struct cache_tree *it,
cache + i, entries - i,
path,
baselen + sublen + 1,
- missing_ok,
- dryrun);
+ flags);
if (subcnt < 0)
return subcnt;
i += subcnt - 1;
@@ -371,15 +372,13 @@ static int update_one(struct cache_tree *it,
int cache_tree_update(struct cache_tree *it,
struct cache_entry **cache,
int entries,
- int missing_ok,
- int dryrun,
- int silent)
+ int flags)
{
int i;
- i = verify_cache(cache, entries, silent);
+ i = verify_cache(cache, entries, flags);
if (i)
return i;
- i = update_one(it, cache, entries, "", 0, missing_ok, dryrun);
+ i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
return 0;
@@ -572,11 +571,9 @@ int write_cache_as_tree(unsigned char *sha1, int flags, const char *prefix)
was_valid = cache_tree_fully_valid(active_cache_tree);
if (!was_valid) {
- int missing_ok = flags & WRITE_TREE_MISSING_OK;
-
if (cache_tree_update(active_cache_tree,
active_cache, active_nr,
- missing_ok, 0, 0) < 0)
+ flags) < 0)
return WRITE_TREE_UNMERGED_INDEX;
if (0 <= newfd) {
if (!write_cache(newfd, active_cache, active_nr) &&
@@ -672,10 +669,10 @@ int cache_tree_matches_traversal(struct cache_tree *root,
return 0;
}
-int update_main_cache_tree (int silent)
+int update_main_cache_tree (int flags)
{
if (!the_index.cache_tree)
the_index.cache_tree = cache_tree();
return cache_tree_update(the_index.cache_tree,
- the_index.cache, the_index.cache_nr, 0, 0, silent);
+ the_index.cache, the_index.cache_nr, flags);
}
diff --git a/cache-tree.h b/cache-tree.h
index 0ec0b2a..d8cb2e9 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -29,13 +29,15 @@ void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
-int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int, int, int);
+int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int);
int update_main_cache_tree(int);
/* bitmasks to write_cache_as_tree flags */
#define WRITE_TREE_MISSING_OK 1
#define WRITE_TREE_IGNORE_CACHE_TREE 2
+#define WRITE_TREE_DRY_RUN 4
+#define WRITE_TREE_SILENT 8
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/merge-recursive.c b/merge-recursive.c
index d83cd6c..6479a60 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -264,7 +264,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (!cache_tree_fully_valid(active_cache_tree) &&
cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0, 0) < 0)
+ active_cache, active_nr, 0) < 0)
die("error building trees");
result = lookup_tree(active_cache_tree->sha1);
diff --git a/test-dump-cache-tree.c b/test-dump-cache-tree.c
index e6c2923..a6ffdf3 100644
--- a/test-dump-cache-tree.c
+++ b/test-dump-cache-tree.c
@@ -59,6 +59,6 @@ int main(int ac, char **av)
struct cache_tree *another = cache_tree();
if (read_cache() < 0)
die("unable to read index file");
- cache_tree_update(another, active_cache, active_nr, 0, 1, 0);
+ cache_tree_update(another, active_cache, active_nr, WRITE_TREE_DRY_RUN);
return dump_cache_tree(active_cache_tree, another, "");
}
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH v2 0/4] Deprecate "not allow as-is commit with i-t-a entries"
From: Nguyễn Thái Ngọc Duy @ 2012-02-07 12:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jonathan Nieder,
Nguyễn Thái Ngọc Duy
- git-add.txt changes are removed. In the end all kinds of commit
behave the same way, not worth putting more explanation during the
transition.
- reword config text and warning text (or more precisely copy/paste
from Junio/Jonathan's words)
- Hard coded release numbers are removed. Now it's simply "in future".
- Step 2 may be too annoying. Users are warned on every commit if
commit.ignoreIntentToAdd is set. I think it's good because it keeps
config file clean, but people may think otherwise.
Nguyễn Thái Ngọc Duy (4):
cache-tree: update API to take abitrary flags
commit: introduce a config key to allow as-is commit with i-t-a entries
commit: turn commit.ignoreIntentToAdd to true by default
commit: remove commit.ignoreIntentToAdd, assume it's always true
builtin/commit.c | 9 ++++++---
cache-tree.c | 35 +++++++++++++++++------------------
cache-tree.h | 5 ++++-
merge-recursive.c | 2 +-
t/t2203-add-intent.sh | 21 ++++++++++++++++++++-
test-dump-cache-tree.c | 2 +-
6 files changed, 49 insertions(+), 25 deletions(-)
--
1.7.8.36.g69ee2
^ permalink raw reply
* [PATCH v2 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Nguyễn Thái Ngọc Duy @ 2012-02-07 12:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jonathan Nieder,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1328618804-31796-1-git-send-email-pclouds@gmail.com>
"git add -N" is introduced some time ago to help prevent users's
forgetting to add new files when committing. "git add -N" sets
CE_INTENT_TO_ADD bit to index, hence i-t-a entries from now on. For
safety reasons, as-is commits in the existence of i-t-a entries are
rejected ("I intend to add these files. If I type "git commit -m foo", it
may be a mistake if those files's contents are not added yet. Stop me in
that case").
However unless you are doing "commit -a" or "commit pathspec", you are
responsible for adding all contents you want to have in the commit
before you run the "git commit" command (and for the purpose of this
statement, "add -N" to tell Git to keey an eye on a path does _not_ add
contents).
A change to the file in the working tree that is left unadded is what
you decided to deliberately leave out of the commit, be it a change to a
path already in HEAD, or a path marked with "add -N". Forgetting to add
modified file and forgetting to add a file you earlier used "add -N"
amount to the same kind of risk, and "git status" is the way to make
sure your partial commit has exactly what you want. If you are not
worried about partial commit, you would be doing "commit -a", so the
"safety" is a moot point.
This patch is the beginning of the deprecation process to remove this
safety check, allowing "git commit" to proceed anyway. The process
consists of three steps to help users get used to new behavior:
1. Introduce a temporary config var, commit.ignoreIntentToAdd to help
the migration process, default to false. If the var is true, the remove
safety check.
Users who encounter the safety check are pointed to
commit.ignoreIntentToAdd documentation and advised to set the variable
to true.
2. A few releases after step 1 is out in the field, turn
commit.ignoreIntentToAdd default value to true (affecting mostly new
users).
Those who decided to stick to "false" from step 1 are warned the "false"
support will soon be gone and encouraged to move to "true" (or simply
remove the config variable).
Those who set the config to "true" is advised to remove it to keep
config file clean.
Those who encountered the safety check and did not bother to set this
config var is left out in the cold.
3. A few more releases after step 2, commit.ignoreIntentToAdd is
removed. There's no way to bring back the safety check.
This patch implements step 1.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 16 ++++++++++++++++
builtin/commit.c | 29 ++++++++++++++++++++++++++---
cache-tree.c | 8 +++++---
cache-tree.h | 1 +
t/t2203-add-intent.sh | 21 ++++++++++++++++++++-
5 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index abeb82b..6839e44 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -831,6 +831,22 @@ commit.template::
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
specified user's home directory.
+commit.ignoreIntentToAdd::
+ When set to `false`, prevent `git commit` from creating a
+ commit from an index that has entries that were added with
+ `git add -N` but have not been updated with real contents, as
+ the user may have forgotten to tell the final contents for
+ these entries. Setting this to `true` makes `git commit`
+ pretend as if these entries do not exist in the index.
++
+The default for this variable is `false`, but it will change to `true`
+in future releases of git. To ease the transition, you may want to set
+it to `true` now and get used to the new behaviour early, or you may
+want to set it to `false` to keep the old behaviour a bit longer. We
+however expect to support setting this to `false` (to keep the current
+behaviour) only for a limited time after the default is changed to
+`true`.
+
credential.helper::
Specify an external helper to be called when a username or
password credential is needed; the helper may consult external
diff --git a/builtin/commit.c b/builtin/commit.c
index bf42bb3..da67653 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -86,6 +86,7 @@ static int all, also, interactive, patch_interactive, only, amend, signoff;
static int edit_flag = -1; /* unspecified */
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int no_post_rewrite, allow_empty_message;
+static int cache_tree_flags;
static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
static char *sign_commit;
@@ -117,6 +118,8 @@ static enum {
} status_format = STATUS_FORMAT_LONG;
static int status_show_branch;
+static int set_commit_ignoreintenttoadd;
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -400,7 +403,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
refresh_cache_or_die(refresh_flags);
- update_main_cache_tree(WRITE_TREE_SILENT);
+ update_main_cache_tree(cache_tree_flags | WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die(_("unable to write new_index file"));
@@ -420,8 +423,21 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
+ if (!set_commit_ignoreintenttoadd) {
+ int i;
+ for (i = 0; i < active_nr; i++)
+ if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
+ break;
+ if (i < active_nr) {
+ error(_("you intended to add \"%s\" but did not add it; not committing\n"
+ "hint: to commit all changes to tracked files, use \"commit -a\"\n"
+ "hint: to commit anyway without adding, set commit.ignoreIntentToAdd to true"),
+ active_cache[i]->name);
+ exit(128); /* die() */
+ }
+ }
if (active_cache_changed) {
- update_main_cache_tree(WRITE_TREE_SILENT);
+ update_main_cache_tree(cache_tree_flags | WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die(_("unable to write new_index file"));
@@ -870,7 +886,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
*/
discard_cache();
read_cache_from(index_file);
- if (update_main_cache_tree(0)) {
+ if (update_main_cache_tree(cache_tree_flags)) {
error(_("Error building trees"));
return 0;
}
@@ -1338,6 +1354,13 @@ static int git_commit_config(const char *k, const char *v, void *cb)
include_status = git_config_bool(k, v);
return 0;
}
+ if (!strcmp(k, "commit.ignoreintenttoadd")) {
+ set_commit_ignoreintenttoadd = 1;
+ if (git_config_bool(k, v))
+ cache_tree_flags |= WRITE_TREE_IGNORE_INTENT_TO_ADD;
+ else
+ cache_tree_flags &= ~WRITE_TREE_IGNORE_INTENT_TO_ADD;
+ }
status = git_gpg_config(k, v, NULL);
if (status)
diff --git a/cache-tree.c b/cache-tree.c
index 16355d6..d0be159 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -159,7 +159,9 @@ static int verify_cache(struct cache_entry **cache,
funny = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
- if (ce_stage(ce) || (ce->ce_flags & CE_INTENT_TO_ADD)) {
+ if (ce_stage(ce) ||
+ ((flags & WRITE_TREE_IGNORE_INTENT_TO_ADD) == 0 &&
+ (ce->ce_flags & CE_INTENT_TO_ADD))) {
if (silent)
return -1;
if (10 < ++funny) {
@@ -339,8 +341,8 @@ static int update_one(struct cache_tree *it,
mode, sha1_to_hex(sha1), entlen+baselen, path);
}
- if (ce->ce_flags & CE_REMOVE)
- continue; /* entry being removed */
+ if (ce->ce_flags & (CE_REMOVE | CE_INTENT_TO_ADD))
+ continue; /* entry being removed or placeholder */
strbuf_grow(&buffer, entlen + 100);
strbuf_addf(&buffer, "%o %.*s%c", mode, entlen, path + baselen, '\0');
diff --git a/cache-tree.h b/cache-tree.h
index d8cb2e9..af3b917 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -38,6 +38,7 @@ int update_main_cache_tree(int);
#define WRITE_TREE_IGNORE_CACHE_TREE 2
#define WRITE_TREE_DRY_RUN 4
#define WRITE_TREE_SILENT 8
+#define WRITE_TREE_IGNORE_INTENT_TO_ADD 16
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 58a3299..88a508e 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -41,7 +41,26 @@ test_expect_success 'cannot commit with i-t-a entry' '
echo frotz >nitfol &&
git add rezrov &&
git add -N nitfol &&
- test_must_fail git commit
+ test_must_fail git commit -minitial
+'
+
+test_expect_success 'can commit tree with i-t-a entry' '
+ git reset --hard &&
+ echo xyzzy >rezrov &&
+ echo frotz >nitfol &&
+ git add rezrov &&
+ git add -N nitfol &&
+ git config commit.ignoreIntentToAdd true &&
+ git commit -m initial &&
+ git ls-tree -r HEAD >actual &&
+ cat >expected <<EOF &&
+100644 blob ce013625030ba8dba906f756967f9e9ca394464a elif
+100644 blob ce013625030ba8dba906f756967f9e9ca394464a file
+100644 blob cf7711b63209d0dbc2d030f7fe3513745a9880e4 rezrov
+EOF
+ test_cmp expected actual &&
+ git config commit.ignoreIntentToAdd false &&
+ git reset HEAD^
'
test_expect_success 'can commit with an unrelated i-t-a entry in index' '
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH v2 3/4] commit: turn commit.ignoreIntentToAdd to true by default
From: Nguyễn Thái Ngọc Duy @ 2012-02-07 12:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jonathan Nieder,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1328618804-31796-1-git-send-email-pclouds@gmail.com>
This is step 2 from commit.ignoreIntentToAdd deprecation plan. To
recap:
2. A few releases after step 1 is out in the field, turn
commit.ignoreIntentToAdd default value to true (affecting mostly new
users).
Those who decided to stick to "false" from step 1 are warned the "false"
support will soon be gone and encouraged to move to "true" (or simply
remove the config variable).
Those who set the config to "true" is advised to remove it to keep
config file clean.
Those who encountered the safety check and did not bother to set this
config var is left out in the cold.
3. A few more releases after step 2, commit.ignoreIntentToAdd is
removed. There's no way to bring back the safety check.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 11 ++++-------
builtin/commit.c | 19 ++++++++++++++++---
t/t2203-add-intent.sh | 4 ++--
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6839e44..fa56753 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -839,13 +839,10 @@ commit.ignoreIntentToAdd::
these entries. Setting this to `true` makes `git commit`
pretend as if these entries do not exist in the index.
+
-The default for this variable is `false`, but it will change to `true`
-in future releases of git. To ease the transition, you may want to set
-it to `true` now and get used to the new behaviour early, or you may
-want to set it to `false` to keep the old behaviour a bit longer. We
-however expect to support setting this to `false` (to keep the current
-behaviour) only for a limited time after the default is changed to
-`true`.
+The default for this variable is `true`. You are discouraged to set it
+to `false` to keep the old behaviour a bit longer because support
+setting this to `false` will be removed in future releases without
+warning.
credential.helper::
Specify an external helper to be called when a username or
diff --git a/builtin/commit.c b/builtin/commit.c
index da67653..cd28081 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -423,15 +423,16 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
- if (!set_commit_ignoreintenttoadd) {
+ if (!(cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)) {
int i;
for (i = 0; i < active_nr; i++)
if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
break;
if (i < active_nr) {
error(_("you intended to add \"%s\" but did not add it; not committing\n"
- "hint: to commit all changes to tracked files, use \"commit -a\"\n"
- "hint: to commit anyway without adding, set commit.ignoreIntentToAdd to true"),
+ "this behavior is deprecated, please set commit.ignoreIntentToAdd\n"
+ "to true or remove the configuration variable. See the configuration\n"
+ "variable documentation for more information."),
active_cache[i]->name);
exit(128); /* die() */
}
@@ -1424,6 +1425,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
git_config(git_commit_config, &s);
determine_whence(&s);
+ if (!set_commit_ignoreintenttoadd)
+ cache_tree_flags |= WRITE_TREE_IGNORE_INTENT_TO_ADD;
+
if (get_sha1("HEAD", sha1))
current_head = NULL;
else {
@@ -1583,5 +1587,14 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!quiet)
print_summary(prefix, sha1, !current_head);
+ if (set_commit_ignoreintenttoadd) {
+ if (cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)
+ warning(_("commit.ignoreIntentToAdd = true is not needed anymore.\n"
+ "Please remove it."));
+ else
+ warning(_("commit.ignoreIntentToAdd = false is deprecated.\n"
+ "Please see the commit.ignoreIntentToAdd documentation for\n"
+ "more information and remove the configuration variable."));
+ }
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 88a508e..09b8bbf 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -41,11 +41,11 @@ test_expect_success 'cannot commit with i-t-a entry' '
echo frotz >nitfol &&
git add rezrov &&
git add -N nitfol &&
- test_must_fail git commit -minitial
+ git commit -minitial
'
test_expect_success 'can commit tree with i-t-a entry' '
- git reset --hard &&
+ git reset --hard HEAD^ &&
echo xyzzy >rezrov &&
echo frotz >nitfol &&
git add rezrov &&
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH v2 4/4] commit: remove commit.ignoreIntentToAdd, assume it's always true
From: Nguyễn Thái Ngọc Duy @ 2012-02-07 12:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jonathan Nieder,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1328618804-31796-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 13 -------------
builtin/commit.c | 35 +----------------------------------
t/t2203-add-intent.sh | 4 ++--
3 files changed, 3 insertions(+), 49 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index fa56753..abeb82b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -831,19 +831,6 @@ commit.template::
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
specified user's home directory.
-commit.ignoreIntentToAdd::
- When set to `false`, prevent `git commit` from creating a
- commit from an index that has entries that were added with
- `git add -N` but have not been updated with real contents, as
- the user may have forgotten to tell the final contents for
- these entries. Setting this to `true` makes `git commit`
- pretend as if these entries do not exist in the index.
-+
-The default for this variable is `true`. You are discouraged to set it
-to `false` to keep the old behaviour a bit longer because support
-setting this to `false` will be removed in future releases without
-warning.
-
credential.helper::
Specify an external helper to be called when a username or
password credential is needed; the helper may consult external
diff --git a/builtin/commit.c b/builtin/commit.c
index cd28081..491cae1 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -118,8 +118,6 @@ static enum {
} status_format = STATUS_FORMAT_LONG;
static int status_show_branch;
-static int set_commit_ignoreintenttoadd;
-
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -423,20 +421,6 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
- if (!(cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)) {
- int i;
- for (i = 0; i < active_nr; i++)
- if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
- break;
- if (i < active_nr) {
- error(_("you intended to add \"%s\" but did not add it; not committing\n"
- "this behavior is deprecated, please set commit.ignoreIntentToAdd\n"
- "to true or remove the configuration variable. See the configuration\n"
- "variable documentation for more information."),
- active_cache[i]->name);
- exit(128); /* die() */
- }
- }
if (active_cache_changed) {
update_main_cache_tree(cache_tree_flags | WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
@@ -1355,13 +1339,6 @@ static int git_commit_config(const char *k, const char *v, void *cb)
include_status = git_config_bool(k, v);
return 0;
}
- if (!strcmp(k, "commit.ignoreintenttoadd")) {
- set_commit_ignoreintenttoadd = 1;
- if (git_config_bool(k, v))
- cache_tree_flags |= WRITE_TREE_IGNORE_INTENT_TO_ADD;
- else
- cache_tree_flags &= ~WRITE_TREE_IGNORE_INTENT_TO_ADD;
- }
status = git_gpg_config(k, v, NULL);
if (status)
@@ -1425,8 +1402,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
git_config(git_commit_config, &s);
determine_whence(&s);
- if (!set_commit_ignoreintenttoadd)
- cache_tree_flags |= WRITE_TREE_IGNORE_INTENT_TO_ADD;
+ cache_tree_flags |= WRITE_TREE_IGNORE_INTENT_TO_ADD;
if (get_sha1("HEAD", sha1))
current_head = NULL;
@@ -1587,14 +1563,5 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!quiet)
print_summary(prefix, sha1, !current_head);
- if (set_commit_ignoreintenttoadd) {
- if (cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)
- warning(_("commit.ignoreIntentToAdd = true is not needed anymore.\n"
- "Please remove it."));
- else
- warning(_("commit.ignoreIntentToAdd = false is deprecated.\n"
- "Please see the commit.ignoreIntentToAdd documentation for\n"
- "more information and remove the configuration variable."));
- }
return 0;
}
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 09b8bbf..6dbfb74 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -44,13 +44,13 @@ test_expect_success 'cannot commit with i-t-a entry' '
git commit -minitial
'
-test_expect_success 'can commit tree with i-t-a entry' '
+test_expect_success 'commit.ignoreIntentToAdd = false is ignored' '
git reset --hard HEAD^ &&
echo xyzzy >rezrov &&
echo frotz >nitfol &&
git add rezrov &&
git add -N nitfol &&
- git config commit.ignoreIntentToAdd true &&
+ git config commit.ignoreIntentToAdd false &&
git commit -m initial &&
git ls-tree -r HEAD >actual &&
cat >expected <<EOF &&
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: cloning a tree which has detached branch checked out
From: Nguyen Thai Ngoc Duy @ 2012-02-07 12:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jakub Narebski, git
In-Reply-To: <20120207104100.GA24828@redhat.com>
On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > #git clone -n lab:/home/mst/scm/linux
>> > ....
>> > error: Trying to write ref HEAD with nonexistant object
>> > cec64082f689f949a397cb9b39423dc41545fa0e
>> > fatal: Cannot update the ref 'HEAD'.
>> >
>> > Looks like a bug, doesn't it?
>>
>> Which git version? IIRC there was some bugfix recently in that
>> area...
>
> Sorry, forgot to mention that. It's pretty recent:
> $ git --version
> git version 1.7.9.111.gf3fb0
The series that Jakub mentioned is probably nd/clone-detached 5ce2b97,
which is already included in your tree. Does 1.7.9 work?
I tried but it was ok for me. I think ref processing at local probably
goes wrong and does not request commit from HEAD. If the repo is not
confidential, you can zip it and send me.
--
Duy
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Michael S. Tsirkin @ 2012-02-07 13:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, git
In-Reply-To: <CACsJy8DtmQLX+Lfng-QRzVg9sfo8gQMXB-xTtPYpt+R2gModTg@mail.gmail.com>
On Tue, Feb 07, 2012 at 07:57:08PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 7, 2012 at 5:41 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > #git clone -n lab:/home/mst/scm/linux
> >> > ....
> >> > error: Trying to write ref HEAD with nonexistant object
> >> > cec64082f689f949a397cb9b39423dc41545fa0e
> >> > fatal: Cannot update the ref 'HEAD'.
> >> >
> >> > Looks like a bug, doesn't it?
> >>
> >> Which git version? IIRC there was some bugfix recently in that
> >> area...
> >
> > Sorry, forgot to mention that. It's pretty recent:
> > $ git --version
> > git version 1.7.9.111.gf3fb0
>
> The series that Jakub mentioned is probably nd/clone-detached 5ce2b97,
> which is already included in your tree. Does 1.7.9 work?
I'll try that.
> I tried but it was ok for me. I think ref processing at local probably
> goes wrong and does not request commit from HEAD. If the repo is not
> confidential, you can zip it and send me.
Can't unfortunately :(
Would some verbose logs help?
> --
> Duy
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Nguyen Thai Ngoc Duy @ 2012-02-07 13:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jakub Narebski, git
In-Reply-To: <20120207130204.GA7600@redhat.com>
On Tue, Feb 7, 2012 at 8:02 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> I tried but it was ok for me. I think ref processing at local probably
>> goes wrong and does not request commit from HEAD. If the repo is not
>> confidential, you can zip it and send me.
>
> Can't unfortunately :(
> Would some verbose logs help?
You can try cloning with GIT_TRACE_PACKET=1. bisect should also help.
--
Duy
^ permalink raw reply
* STGIT: Deathpatch in linus tree
From: "Andy Green (林安廸)" @ 2012-02-07 13:02 UTC (permalink / raw)
To: git
Hi -
Linus just pushed 105e5180936d69b1aee46ead8a5fc6c68f4d5f65 to
linux-2.6... along the lines of the Monty Python joke that was so funny
it kills anyone who hears it, if I have a stgit branch based on a HEAD
that includes this commit then stgit dies when pushing on top of it.
So...
[agreen@build linux-2.6]$ stg pop --all
[agreen@build linux-2.6]$ git reset --hard 96e02d1
HEAD is now at 96e02d1 exec: fix use-after-free bug in setup_new_exec()
[agreen@build linux-2.6]$ stg push
Pushing patch "subject-patch-1-3-arm-dt-add-p" ... done (empty)
Now at patch "subject-patch-1-3-arm-dt-add-p"
[agreen@build linux-2.6]$ stg pop
Popped subject-patch-1-3-arm-dt-add-p
No patch applied
So the commit just before the bad guy is happy. Then -->
[agreen@build linux-2.6]$ git reset --hard 105e518
HEAD is now at 105e518 Merge tag 'hwmon-fixes-for-3.3-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
[agreen@build linux-2.6]$ stg push
Error: Unhandled exception:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/stgit/main.py", line 152, in _main
ret = command.func(parser, options, args)
File "/usr/lib/python2.7/site-packages/stgit/commands/push.py", line
68, in func
check_clean_iw = clean_iw)
File "/usr/lib/python2.7/site-packages/stgit/lib/transaction.py", line
95, in __init__
self.__current_tree = self.__stack.head.data.tree
File "/usr/lib/python2.7/site-packages/stgit/lib/git.py", line 426, in
data
self.__repository.cat_object(self.sha1))
File "/usr/lib/python2.7/site-packages/stgit/lib/git.py", line 408, in
parse
assert False
AssertionError
It also dies if I use Linus' current HEAD as the basis I am stgitting on
top of, which is one patch ahead of the deathpatch.
I'm using Fedora rawhide versions of git and stgit
git-1.7.9-1.fc17.x86_64
stgit-0.15-2.fc17.noarch
-Andy
^ 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