* Re: Is ./git/branches used for anything?
From: Sverre Rabbelier @ 2010-02-02 8:11 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-35461E.00013102022010@news.gmane.org>
Heya,
On Tue, Feb 2, 2010 at 09:01, Ron Garret <ron1@flownet.com> wrote:
> If so, what? .git/refs/heads seems to contain all the branch info, so
> what is the branches directory for?
It's a leftover from the good ole' days. I think Cogito used it.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: How can I create a commit without a parent?
From: Junio C Hamano @ 2010-02-02 8:05 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-5383E3.00002602022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> git commit-tree insists on having at least one parent commit at
> the command line.
Incorrect. "git commit" might but "git commit-tree" does. Perhaps you
are forgetting that the first object name is a tree to be wrapped.
A short answer is that you don't create a root commit twice in a single
repository, period. Your repository _may_ be end up with more than one
root but that typically is due to you fetching unrelated histories from
different repositories, each created its own root.
^ permalink raw reply
* Is ./git/branches used for anything?
From: Ron Garret @ 2010-02-02 8:01 UTC (permalink / raw)
To: git
If so, what? .git/refs/heads seems to contain all the branch info, so
what is the branches directory for?
Thanks,
rg
^ permalink raw reply
* Re: What does git reset do?
From: Octavio Alvarez @ 2010-02-02 8:01 UTC (permalink / raw)
To: Ron Garret, git
In-Reply-To: <ron1-A2A2DE.23475601022010@news.gmane.org>
On Mon, 01 Feb 2010 23:47:56 -0800, Ron Garret <ron1@flownet.com> wrote:
> The docs say that git-reset:
>
> "Sets the current head to the specified commit..."
... without modifying your working copy if --soft, and modifying your
working copy if --hard.
... and without switching branches (you want git checkout for that).
> So I tried this:
>
> [ron@mickey:~/devel/gittest]$ git branch
> * br1
> master
> [ron@mickey:~/devel/gittest]$ git reset --soft master
>
>
> ...expecting HEAD to now point to master. But it doesn't:
It actually does. HEAD (and br1) now point to [the commit pointed to by]
master. Your working copy was left intact (because of --soft). Compare
with "git checkout".
gitk --all is your friend to better understand this.
Your branch is still br1. It means, if you commit, br1 will advance, (not
master). But, given your git reset, instead of committing over [the commit
pointed to by previous] br1, you will commit over [the commit pointed to
by] master.
Be careful though, you might lose commits with git reset.
> [ron@mickey:~/devel/gittest]$ git branch
> * br1
> master
> [ron@mickey:~/devel/gittest]$ more .git/HEAD
> ref: refs/heads/br1
>
>
> So... what does git reset do?
Sets the current head (and branch, if not detached) to the specified
commit...
--
--
Octavio.
^ permalink raw reply
* How can I create a commit without a parent?
From: Ron Garret @ 2010-02-02 8:00 UTC (permalink / raw)
To: git
SLSIA. git commit-tree insists on having at least one parent commit at
the command line. From reverse-engineering it seems like I could do it
by setting .git/HEAD to 'ref: refs/heads/some-nonexistent-branch' but
mucking with HEAD directly like that feels kinda scary.
Thanks,
rg
^ permalink raw reply
* Re: [RFC/PATCH 5/6] revert: add --ff option to allow fast forward when cherry-picking
From: Paolo Bonzini @ 2010-02-02 7:56 UTC (permalink / raw)
To: Christian Couder
Cc: Christian Couder, Junio C Hamano, git, Linus Torvalds,
Johannes Schindelin, Stephan Beyer, Daniel Barkalow
In-Reply-To: <201002020613.48067.chriscool@tuxfamily.org>
>> and that even without
>> setting the variables, "git cherry-pick" will pick a new commit date but
>> "git cherry-pick --ff" wouldn't. The latter, I think is the only
>> difference that is worth pondering further.
>
> Because --no-ff could be used when the GIT_COMMITTER_* and GIT_AUTHOR_* env
> variable should be respected? Or because we should check if one of these
> env variable is set and, if that is the case, we should not fast forward?
I wish it could be the former, at least in the long run; after all git
merge fast-forwards by default, and it doesn't adjust its behavior if
GIT_COMMITTER_* is passed.
Anyway, your plan of starting with --ff and changing the default to
--no-ff later seems fine. Maybe you can add --no-ff now already, though
it would be a no-op.
>> Note that "-e --ff" would error out; however if --ff would be the
>> default, "-e" would probably choose between fast-forward and
>> non-fast-forward depending on whether the commit message was edited.
>
> Yeah, but let's change the default later please.
Sure.
Paolo
^ permalink raw reply
* What does git reset do?
From: Ron Garret @ 2010-02-02 7:47 UTC (permalink / raw)
To: git
The docs say that git-reset:
"Sets the current head to the specified commit..."
So I tried this:
[ron@mickey:~/devel/gittest]$ git branch
* br1
master
[ron@mickey:~/devel/gittest]$ git reset --soft master
...expecting HEAD to now point to master. But it doesn't:
[ron@mickey:~/devel/gittest]$ git branch
* br1
master
[ron@mickey:~/devel/gittest]$ more .git/HEAD
ref: refs/heads/br1
So... what does git reset do?
Thanks,
rg
^ permalink raw reply
* Re: A git-mv question
From: Ron Garret @ 2010-02-02 7:21 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.1002011927490.1681@xanadu.home>
In article <alpine.LFD.2.00.1002011927490.1681@xanadu.home>,
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 1 Feb 2010, Ron Garret wrote:
>
> > If I do a git-mv *and* edit the file all in one commit, does that get
> > recorded in a way that allows git to track the change through the
> > changed file name? In other words, if I do just a git-mv (without
> > changing the file) git can track that by observing that two differently
> > named objects in two different commit trees contain the same blob. But
> > if the file is edited then the blobs will be different. Is git smart
> > enough to distinguish a git-mv and edit from, say, the equivalent git-rm
> > and git-add? If so, how does it do it?
>
> Please see:
>
> http://www.kernel.org/pub/software/scm/git/docs/gitdiffcore.html
>
Thanks! A little light reading :-)
rg
^ permalink raw reply
* Re: working directory umask
From: Junio C Hamano @ 2010-02-02 6:43 UTC (permalink / raw)
To: D Herring; +Cc: git
In-Reply-To: <hk8gq7$o76$1@ger.gmane.org>
D Herring <dherring@tentpost.com> writes:
> One problem: Even though the working directory is g+swx and git was
> initialized with --shared=group or --shared=0660, the checked out
> source files still don't have group write permissions...
It is working as designed. "shared" setting is about a shared central
repository that is typically a bare repository, and currently it is
implemented as such.
You could argue that the behaviour for the work tree files is undefined
and make the code act differently, though.
In any case, it would be better to document this, and it might even make
sense to issue a warning message when we detect the repository is used
with a work tree (including the use of GIT_DIR and GIT_WORK_TREE
environment variables to temporarily turn a bare repository with a work
tree).
Thanks for a report.
^ permalink raw reply
* Re: Delivery Status Notification (Failure)
From: Laszlo Papp @ 2010-02-02 6:37 UTC (permalink / raw)
To: Frank Li; +Cc: Tay Ray Chuan, git, normalperson
In-Reply-To: <1976ea661002012030h23aa415ek30aa6db23cb88d0e@mail.gmail.com>
> The basic requirement is git svn can provide a way to prompt a dialog
> box to input passwd.
Yeah, it's a very basic use case, but I don't know whether there is a
workaround for it somehow, maybe perl gurus or git svn users could
help more...
My company, where there are windows users (95% of the company), would
like to use TortoiseGIT as a graphical client for SVN server
repositories as an SVN client, no other way by us, so it'd be high
priority :) So I've got a beer for any volunteer, thanks :P
Best Regards,
Laszlo Papp
^ permalink raw reply
* working directory umask
From: D Herring @ 2010-02-02 6:30 UTC (permalink / raw)
To: git
Hi all,
So for one project at work, we have a (slow) server with a common
build area. Standard practice has been to extract a tarball,
configure, make, make install into a common area. I have started
using git to replace the tarballs -- keep version info, make doesn't
have to rebuild everything, auto-tag install sources, etc.
One problem: Even though the working directory is g+swx and git was
initialized with --shared=group or --shared=0660, the checked out
source files still don't have group write permissions...
Is there an option that I've overlooked? I can't seem to find
anything that overrides umask in the working directory, only in the repo.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 0/2] upload-pack: pre- and post- hooks
From: Nicolas Pitre @ 2010-02-02 6:15 UTC (permalink / raw)
To: Arun Raghavan; +Cc: Shawn O. Pearce, git
In-Reply-To: <6f8b45101002012152y76bccb65n78235fce170675ef@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1531 bytes --]
On Tue, 2 Feb 2010, Arun Raghavan wrote:
> On 1 February 2010 22:06, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Nicolas Pitre <nico@fluxnic.net> wrote:
> >> On Mon, 1 Feb 2010, Shawn O. Pearce wrote:
> >> I think such hooks could be allowed only if triggered explicitly by the
> >> upload-pack caller, such as git-daemon. That's probably the only
> >> scenario where a useful use case can be justified for them anyway.
> >>
> >> And of course, to avoid any security problems, the actual hooks must not
> >> be provided by the repository owner but provided externally, like from
> >> git-daemon, via some upload-pack command line arguments. This way the
> >> hooks are really controlled by the system administrator managing
> >> git-daemon and not by any random git repository owner.
> >>
> >> That should be good enough for all the use cases those hooks were
> >> originally designed for.
> >
> > Oooh, I like that.
> >
> > If the paths to the hooks are passed in on the command line of
> > git-upload-pack, and git-daemon takes those options and passes
> > them through, you're right, we probably get everything we need.
> >
> > Gitosis can still use the hooks if it wants, since it controls
> > the call of git-upload-pack.
>
> I can add the uid check before running the hook as well. Is that good
> enough, or would you guys like me to start from scratch with the
> command-line argument approach?
Please forget the uid check and go with the command-line argument
approach. That's the only sane solution.
Nicolas
^ permalink raw reply
* Re: [PATCH 0/2] upload-pack: pre- and post- hooks
From: Arun Raghavan @ 2010-02-02 5:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20100201163618.GB9394@spearce.org>
On 1 February 2010 22:06, Shawn O. Pearce <spearce@spearce.org> wrote:
> Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Mon, 1 Feb 2010, Shawn O. Pearce wrote:
>> I think such hooks could be allowed only if triggered explicitly by the
>> upload-pack caller, such as git-daemon. That's probably the only
>> scenario where a useful use case can be justified for them anyway.
>>
>> And of course, to avoid any security problems, the actual hooks must not
>> be provided by the repository owner but provided externally, like from
>> git-daemon, via some upload-pack command line arguments. This way the
>> hooks are really controlled by the system administrator managing
>> git-daemon and not by any random git repository owner.
>>
>> That should be good enough for all the use cases those hooks were
>> originally designed for.
>
> Oooh, I like that.
>
> If the paths to the hooks are passed in on the command line of
> git-upload-pack, and git-daemon takes those options and passes
> them through, you're right, we probably get everything we need.
>
> Gitosis can still use the hooks if it wants, since it controls
> the call of git-upload-pack.
I can add the uid check before running the hook as well. Is that good
enough, or would you guys like me to start from scratch with the
command-line argument approach?
Cheers,
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
^ permalink raw reply
* Re: [PATCH 0/2] upload-pack: pre- and post- hooks
From: Arun Raghavan @ 2010-02-02 5:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100201160141.GG8916@spearce.org>
On 1 February 2010 21:31, Shawn O. Pearce <spearce@spearce.org> wrote:
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> On 1 February 2010 20:50, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > Arun Raghavan <ford_prefect@gentoo.org> wrote:
[...]
>> >> At some point if the future, if needed, this could also be made a part of the
>> >> negotiation between the client and server.
>> >
>> > I'm not sure I follow.
>> >
>> > Are you proposing the server advertises that it wants to run hooks,
>> > and lets the client decide whether or not they should be executed?
>>
>> Something like that. I was thinking the client could always advertise
>> whether the it wants to allow the hooks to be executed or not (which
>> would override the default value of the global variable I introduced).
>> Either approach would work, though the second is simpler but also
>> dumber.
>>
>> Again, this might be over-complicating things, which is why I did not
>> implement it. I just wanted to make a note of the fact that this could
>> be done if the need is felt.
>
> My concern with this is, users might disable the hook all of the
> time, and then servers that actually want the hook (e.g. gentoo's
> use of the pre-upload-pack to avoid initial clones over git://)
> would be stuck, just like they are today.
>
> No, its just not sane to give the user a choice whether or not they
> should execute something remotely.
Ah, sorry I wasn't clear about this. I've made it so that when
pre-upload-pack fails, the entire operation fails. This makes sense
because pre-upload-pack is meant to check things like "do we want
allow the user to get the pack". For post-upload-pack, failure only
results in a warning, since the actual upload is already done and
there's not much to do other than log the failure.
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
^ permalink raw reply
* Re: [PATCH] resolve-undo.c: silence compiler complaints by casting void * to char *
From: Junio C Hamano @ 2010-02-02 5:46 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <7vsk9kplla.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks for catching this.
>
> In this particular case, I however suspect that it would be cleaner to
> declare that the first parameter to resolve_undo_read() is a "char *"
> (or even "const char *"), as we are dealing with NUL delimited list of
> octal numbers and character strings.
It would look like this. I wonder if we should make hash*() inline
functions to take (void *) or (const void *) pointers to avoid further
noises like this but that would be a separate topic.
resolve-undo.c | 4 ++--
resolve-undo.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/resolve-undo.c b/resolve-undo.c
index 37d73cd..0f50ee0 100644
--- a/resolve-undo.c
+++ b/resolve-undo.c
@@ -53,7 +53,7 @@ void resolve_undo_write(struct strbuf *sb, struct string_list *resolve_undo)
for_each_string_list(write_one, resolve_undo, sb);
}
-struct string_list *resolve_undo_read(void *data, unsigned long size)
+struct string_list *resolve_undo_read(const char *data, unsigned long size)
{
struct string_list *resolve_undo;
size_t len;
@@ -93,7 +93,7 @@ struct string_list *resolve_undo_read(void *data, unsigned long size)
continue;
if (size < 20)
goto error;
- hashcpy(ui->sha1[i], data);
+ hashcpy(ui->sha1[i], (const unsigned char *)data);
size -= 20;
data += 20;
}
diff --git a/resolve-undo.h b/resolve-undo.h
index e4e5c1b..8458769 100644
--- a/resolve-undo.h
+++ b/resolve-undo.h
@@ -8,7 +8,7 @@ struct resolve_undo_info {
extern void record_resolve_undo(struct index_state *, struct cache_entry *);
extern void resolve_undo_write(struct strbuf *, struct string_list *);
-extern struct string_list *resolve_undo_read(void *, unsigned long);
+extern struct string_list *resolve_undo_read(const char *, unsigned long);
extern void resolve_undo_clear_index(struct index_state *);
extern int unmerge_index_entry_at(struct index_state *, int);
extern void unmerge_index(struct index_state *, const char **);
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-02-02 5:43 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-0A5B25.21231201022010@news.gmane.org>
On Mon, 1 Feb 2010, Ron Garret wrote:
> Nicolas Pitre <nico@fluxnic.net> wrote:
>
> > It is good of course that you bring those issues to our attention. but
> > it is more likely that the manual needs fixing than anything else.
>
> That's fine. My only aim here is to raise the issue.
>
> By the way, if you (plural) think it would be helpful I'd be happy to
> take a stab at rewriting this part of the manual. Writing docs is a
> drag, but it would probably be a useful exercise for me.
Please feel free to contribute. We are all volunteers here and extra
help is always welcome. The file Documentation/SubmittingPatches should
give you lots of useful hints.
Nicolas
^ permalink raw reply
* Re: [PATCH 8/8 v6] gitweb: Add an option to force version match
From: Junio C Hamano @ 2010-02-02 5:26 UTC (permalink / raw)
To: J.H.; +Cc: Jakub Narebski, git, John 'Warthog9' Hawley, Petr Baudis
In-Reply-To: <4B677971.2080100@eaglescrag.net>
"J.H." <warthog9@eaglescrag.net> writes:
> Starting to pop off the stack, and this came up first. A quick reading
> of this, I'd sign-off and agree to patches 1-7 completely.
Then let me queue up to 7th to 'next', so I do not have to mentally keep
track of which ones are already judged to be good, and we can move forward
immediately after 1.7.0 ships, regardless of the discusson on the 8th one.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-02-02 5:23 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.1002012253260.1681@xanadu.home>
In article <alpine.LFD.2.00.1002012253260.1681@xanadu.home>,
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 1 Feb 2010, Ron Garret wrote:
>
> > In article <20100202001530.GL9553@machine.or.cz>,
> > Petr Baudis <pasky@suse.cz> wrote:
> >
> > > On Mon, Feb 01, 2010 at 03:56:31PM -0800, Ron Garret wrote:
> > > > In article <7vwrywplxz.fsf@alter.siamese.dyndns.org>,
> > > > Junio C Hamano <gitster@pobox.com> wrote:
> > > > > Ron Garret <ron1@flownet.com> writes:
> > > > > > And as long as I'm weighing in, it would also help to prevent
> > > > > > confusion
> > > > > > if it were made clear that this unnamed branch doesn't actually
> > > > > > come
> > > > > > into existence unless and until you do a commit.
> > > > >
> > > > > This shows that you are still thinking a branch is a line (or
> > > > > multiple
> > > > > lines). It is not.
> > > >
> > > > The git user's guide says it is:
> > > >
> > > > "When we need to be precise, we will use the word "branch" to mean a
> > > > line of development..."
> > > >
> > > > But I understand that a branch is not necessarily a line. In general
> > > > it's a DAG. I get that.
> > >
> > > Again, no. In the most narrow sense, "branch == branch head".
> >
> > The manual specifically contradicts you, so either you are wrong or the
> > manual is wrong.
>
> In that case it's most probably the manual which is wrong.
OK. That happens.
> > Don't forget that what is at issue here is not how git works (I'm pretty
> > sure everyone is on the same page about that) but how to explain it to
> > someone who is not already familiar with it. So it's important to use
> > terminology that is consistent with what the manual says.
>
> Or rather that the manual has to be debugged and be brought in sync with
> reality.
Sure. I'm agnostic about how this synchronization happens. But I think
it's important that it happen, otherwise a lot of people will remain
confused, and that would be a shame.
> All the people who had their hands dirty with the code usually
> hang here, and what they say has precedence with whatever is in the
> manual.
Yes, but what they say still ought to pass some basic tests of utility.
For example, a definition of "branch" that makes it effectively
synonymous with "commit" is probably not useful.
> It is good of course that you bring those issues to our attention. but
> it is more likely that the manual needs fixing than anything else.
That's fine. My only aim here is to raise the issue.
By the way, if you (plural) think it would be helpful I'd be happy to
take a stab at rewriting this part of the manual. Writing docs is a
drag, but it would probably be a useful exercise for me.
rg
^ permalink raw reply
* Re: [RFC/PATCH 5/6] revert: add --ff option to allow fast forward when cherry-picking
From: Christian Couder @ 2010-02-02 5:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christian Couder, Junio C Hamano, git, Linus Torvalds,
Johannes Schindelin, Stephan Beyer, Daniel Barkalow
In-Reply-To: <4B66E53D.8050204@gnu.org>
On lundi 01 février 2010, Paolo Bonzini wrote:
> On 02/01/2010 01:43 PM, Christian Couder wrote:
> > Maybe it could be the default, but in this case it should be made
> > compatible with -n option (and perhaps other options) for backward
> > compatibility, and this would probably need more involved changes.
>
> A better objection is that GIT_COMMITTER_* is respected by |git
> cherry-pick" but not by "git cherry-pick --ff",
Yes, indeed! Good catch!
> and that even without
> setting the variables, "git cherry-pick" will pick a new commit date but
> "git cherry-pick --ff" wouldn't. The latter, I think is the only
> difference that is worth pondering further.
Because --no-ff could be used when the GIT_COMMITTER_* and GIT_AUTHOR_* env
variable should be respected? Or because we should check if one of these
env variable is set and, if that is the case, we should not fast forward?
As I think it would be a big backward incompatibility to force people to
update their scripts to add --no-ff, I think you probably suggest the
latter. This mean that we could have both --ff and --no-ff. --ff could
force fast forward even if some of the above env variables are set. --no-ff
would disable fast forward even if none of the above env variable is set.
> My impression is that a user would never have any problem with
> fast-forwarding. For scripts probably the same is true (the typical
> scenario for scripts is probably very similar to what "git rebase -i"
> does), but it can still be a potential backwards-incompatibility in case
> the script is *expecting* cherry-picking to generate a new SHA1. How
> broken can we consider this expectation?
I am not too worried by this expectation, but I think that, as it looks like
we will need --ff anyway, it is safer to start by implementing --ff like I
did and then later we can implement --no-ff and change the default (when
neither --ff nor --no-ff is used) to look at env variables (or config
variables) to decide if we will fast forward or not.
> That said, to reply to your question, of course -n would disable it, and
> so would -x, -s and possibly -e. But then, the same applies to --ff:
> your patch forbids "-n --ff", but -x, -s and -e would need the same
> treatment.
Yeah, I will add the same treatment for these options.
> Note that "-e --ff" would error out; however if --ff would be the
> default, "-e" would probably choose between fast-forward and
> non-fast-forward depending on whether the commit message was edited.
Yeah, but let's change the default later please.
Thanks,
Christian.
^ permalink raw reply
* Re: Delivery Status Notification (Failure)
From: Frank Li @ 2010-02-02 4:30 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Laszlo Papp, git, normalperson
In-Reply-To: <be6fef0d1002012015q2a10af1cq4c5e5f968039ee45@mail.gmail.com>
2010/2/2 Tay Ray Chuan <rctay89@gmail.com>:
> Hi,
>
> On Fri, Jan 29, 2010 at 11:04 PM, Frank Li <lznuaa@gmail.com> wrote:
>> I prefer git-svn can provide environment to launch a external
>> application to input password like open ssh.
>
> how about users who are authenticating over http with basic and
> digest? How does one go about launching an external app for password
> input in those cases?
There are not problem if run git svn clone from console.
But a gui application, such tortoisegit, launch "git svn clone" and
capture git svn clone output.
If passwd needed, git svn clone will read character from console but
GUI application don't know that and wait git svn output.
So there are dead lock till timeout and fail.
The same problem has been happen at ssh. But OpenSSH provide a
option, environment SSH_ASKPASS, which point to a application. when
passwd need, openssh launch this GUI application, user can input
passwd at this GUI application.
The basic requirement is git svn can provide a way to prompt a dialog
box to input passwd.
Frank Li
^ permalink raw reply
* Re: Delivery Status Notification (Failure)
From: Tay Ray Chuan @ 2010-02-02 4:15 UTC (permalink / raw)
To: Frank Li; +Cc: Laszlo Papp, git, normalperson
In-Reply-To: <1976ea661001290704h3ed4761dscf95ba848b373555@mail.gmail.com>
Hi,
On Fri, Jan 29, 2010 at 11:04 PM, Frank Li <lznuaa@gmail.com> wrote:
> I prefer git-svn can provide environment to launch a external
> application to input password like open ssh.
how about users who are authenticating over http with basic and
digest? How does one go about launching an external app for password
input in those cases?
Please don't take this as a criticism of your personal preference. I
believe this feature would make things convenient for users who want
it - those who don't, nothing changes.
Even ssh (via ssh-keygen) lets you specify the passphrase at
command-run time. Others include htpasswd, htdigest...
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-02-02 4:05 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-9A9CEA.16452601022010@news.gmane.org>
On Mon, 1 Feb 2010, Ron Garret wrote:
> In article <20100202001530.GL9553@machine.or.cz>,
> Petr Baudis <pasky@suse.cz> wrote:
>
> > On Mon, Feb 01, 2010 at 03:56:31PM -0800, Ron Garret wrote:
> > > In article <7vwrywplxz.fsf@alter.siamese.dyndns.org>,
> > > Junio C Hamano <gitster@pobox.com> wrote:
> > > > Ron Garret <ron1@flownet.com> writes:
> > > > > And as long as I'm weighing in, it would also help to prevent confusion
> > > > > if it were made clear that this unnamed branch doesn't actually come
> > > > > into existence unless and until you do a commit.
> > > >
> > > > This shows that you are still thinking a branch is a line (or multiple
> > > > lines). It is not.
> > >
> > > The git user's guide says it is:
> > >
> > > "When we need to be precise, we will use the word "branch" to mean a
> > > line of development..."
> > >
> > > But I understand that a branch is not necessarily a line. In general
> > > it's a DAG. I get that.
> >
> > Again, no. In the most narrow sense, "branch == branch head".
>
> The manual specifically contradicts you, so either you are wrong or the
> manual is wrong.
In that case it's most probably the manual which is wrong.
> Don't forget that what is at issue here is not how git works (I'm pretty
> sure everyone is on the same page about that) but how to explain it to
> someone who is not already familiar with it. So it's important to use
> terminology that is consistent with what the manual says.
Or rather that the manual has to be debugged and be brought in sync with
reality. All the people who had their hands dirty with the code usually
hang here, and what they say has precedence with whatever is in the
manual.
It is good of course that you bring those issues to our attention. but
it is more likely that the manual needs fixing than anything else.
Nicolas
^ permalink raw reply
* Re: [PATCH 8/8 v6] gitweb: Add an option to force version match
From: Junio C Hamano @ 2010-02-02 3:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: J.H., git, John 'Warthog9' Hawley, Petr Baudis
In-Reply-To: <201002020235.19943.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Mon, 1 Feb 2010, at 17:01:37 -0800, J.H. wrote:
>
>> Starting to pop off the stack, and this came up first. A quick reading
>> of this, I'd sign-off and agree to patches 1-7 completely.
>>
>> I'm still going to take issue that this being off by default is the
>> wrong behavior and leaving this off by default more or less means that
>> it will never get run and it becomes useless code. If this isn't on by
>> default, it shouldn't be committed, as I can't think of a legitimate use
>> case where an admin is going to turn this on.
>
> Well, I don't think that mismatched git and gitweb version should be
> serious problem in practice, unless they are seriously out of sync.
> And in such situation (where either git is stale and gitweb updated,
> or git updated and gitweb kept stale e.g. because it is heavily
> customized with not ported changes) gitweb admin should turn this
> feature on.
I am not quite sure why the "boolean" default matters that much to deserve
this much of bandwidth.
If it is assumed that most everybody uses matching git and gitweb given by
their distro, then the default does not matter to them. So let's think
about others.
If it is by default on, then here are what the site administrators would
do:
- Some may want to _always_ make sure they run matching versions and
consider having different versions of git and gitweb as _a mistake_; .
they leave the check on by default, and they don't have to do anything.
- Some may _not_ even care. They flip it off, and keep it that way.
They do that _only_ once.
Between these two classes of people, if you make the default off, you are
making more careful ones pay a bit more "one time" price, while allowing
lazy ones potentially shoot themselves in the foot more easily. As the
maintainer, I am sympathetic John's insistence of having this check on by
default, and would even suggest that the configuration variable has to be
set to the exact string "I accept the risk of running non-matching
versions of git and gitweb" to turn the warning off ;-), but either way,
it doesn't seem to make too much of a difference.
Admittedly, unlike John or Pasky, I do not run a public gitweb instanace
nor have to deal with error reports from the end users, and that might be
contributing to my bias.
But I think we need to try helping the third category of people:
- Some may need to _keep_ unmatched versions of git and gitweb for the
users on their box. Perhaps interactive users need a certain version
of git, but they want to show spiffier looking gitweb to the general
public by installing newer one. They check if the combination of the
particular (older) git and (newer) gitweb work well together, and then
they say "don't warn, I know it is Ok _now_".
Unless the configuration can express "this combination has been checked,
so do not warn, but do warn when any other untested combination is being
used", this class of people won't be helped by having a configuration.
They instead have to _remember_ that they need to flip the warning bit on
before updating their git and/or gitweb, only to get reminded that they
need to make sure the combination works well.
That's a funny chicken-and-egg problem, isn't it?
^ permalink raw reply
* Re: Better cooperation between checkouts and stashing
From: Petr Baudis @ 2010-02-02 1:36 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Markus Elfring, Junio C Hamano, git
In-Reply-To: <76c5b8581002011444t4f955fcdrd1f582f5c043f705@mail.gmail.com>
On Mon, Feb 01, 2010 at 05:44:25PM -0500, Eugene Sajine wrote:
> >
> > I imagine that this case is useful because of usual work interruptions
> >
> > in software development. A developer tries to bring various tasks
> >
> > forward in parallel. Branches will be switched often with unfinished
> >
> > work that needs to be kept before the reactivation of another task.
> >
>
> Aren't this and similar statements based on a general problem of
> people being afraid to commit, because CVS/SVN taught them to be
> affraid? We are in progress of migrating from CVS to GIT and this is
> one of the things i'm desperately fighting with.
> In Git Commit doesn't equal Share (it does in CVS), so why not to
> commit and save your work in progress and switch branches painlessly?
There are various pressures pushing against each other and the balance
will be different for each individual and each project. One aspect is
that committing often is encouraged. However, greatly contradicting
force is the pressure to have "clean history" - that is, self-contained,
clearly separated cnd bisectable ommits which introduce independent
changes and are pretty to look at, frequently quite different to
chronological log of the performed work.
Of course you can ignore that and just commit away, or build up large
changes "in advance", then split them up at once. The resulting number
of commits will be about the same, but their quality _and_ the spent
effort will be quite different. Optimum lies in appropriate balance of
the processes, as usual.
There are several ways to achieve the latter process, moreover. One
possibility is to do all changes in the working tree, then carefulling
factoring out various aspects to separate commits using index
manipulation and heavy `git add -p` usage; you would then certainly need
`git stash` in case you wanted to switch the branch. The other way is
to commit regularly creating a history structure similar to the
"careless committer", _however_ before pushing out and publishing the
commits, the history gets cleaned up and rewritten by `git rebase -i`.
Choosing the appropriate method involves all kinds of subtle tradeoffs
and I wonder whether there is a single good answer, it is a matter of
taste. I do the former, but maybe that's because I just dislike rebase
for different reasons. ;-) One natural way would be to hack in the
working tree, splitting up your work to 1-3 commits in the index, then
reviewing your complete local changeset and tweaking it by rebase -i
before finally publishing your self-contained masterpiece.
For better or worse, There Is More Than One Way To Do It in Git. ;-)
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: [PATCH 8/8 v6] gitweb: Add an option to force version match
From: Jakub Narebski @ 2010-02-02 1:35 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley, Petr Baudis
In-Reply-To: <4B677971.2080100@eaglescrag.net>
On Mon, 1 Feb 2010, at 17:01:37 -0800, J.H. wrote:
> Starting to pop off the stack, and this came up first. A quick reading
> of this, I'd sign-off and agree to patches 1-7 completely.
>
> I'm still going to take issue that this being off by default is the
> wrong behavior and leaving this off by default more or less means that
> it will never get run and it becomes useless code. If this isn't on by
> default, it shouldn't be committed, as I can't think of a legitimate use
> case where an admin is going to turn this on.
Well, I don't think that mismatched git and gitweb version should be
serious problem in practice, unless they are seriously out of sync.
And in such situation (where either git is stale and gitweb updated,
or git updated and gitweb kept stale e.g. because it is heavily
customized with not ported changes) gitweb admin should turn this
feature on.
>
> I'd still argue this needs to be on by default to at least give admins
> the explicit warning that if they want to deviate they are taking their
> own risks, and that gitweb might not run as expected. Once the warning
> is disabled in a configuration file it's not like it's going to be
> re-enabled. People loading gitweb from their distro's package
> management will likely be in sync properly and will never see this.
> Those who are installing gitweb independent of their distro's package
> management will at least be warned of the risk, at least until better
> error reporting is done and in gitweb.
If you want to have it turned on by default (which is _incompatible_
change, and which was not announced enough, I think; it might mean
that gitweb can stop working after git or gitweb update), beside
changing commit message and gitweb/README (and of course definition of
$git_versions_must_match variable), you would have also update
explanation in die_error for version mismatch.
Current version, as requested by Petr 'Pasky' Baudis, explains how
to turn feature off if it was enabled. For this it needs to check
which config file is present, but we know at least that some config
file had to be used (beside possibility of hand-editing gitweb.cgi).
This is not the case if this feature is turned on by default: there
is possible that there is no gitweb config file, and all configuration
was done at build time. How to explain then how to turn this feature
off? What happens if both $GIWEB_CONFIG and $GITWEB_CONFIG_SYSTEM
are empty because of misconfiguration during build ($GITWEB_CONFIG
is set by default to gitweb_config.perl, and $GITWEB_CONFIG_SYSTEM
is set by default to /etc/gitweb.conf)? Which one to recommend if both
variables are set, but neither file exists?
The difficulty of explanation how to turn this feature off if it is
on by default was one of main reasons to not have it turned on by
default.
Side-note: Perhaps error is too strong a measure, and it would be better
to just issue warning somewhere instead?
>
> I've got a slightly modified version of this that re-enables it by
> default, it passes t9501 for me.
As it should, because gitweb-lib.sh was modified to explicitly turn off
this feature (see below), to allow testing gitweb without need to
recompile whole git, and to allow testing _not installed_ (source)
version of gitweb.
> > diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> > index 5a734b1..66a3e2d 100755
> > --- a/t/gitweb-lib.sh
> > +++ b/t/gitweb-lib.sh
> > @@ -26,6 +26,7 @@ our \$projects_list = '';
> > our \$export_ok = '';
> > our \$strict_export = '';
> > our \$maxload = undef;
> > +our \$git_versions_must_match = 0;
> >
> > EOF
> >
--
Jakub Narebski
Poland
^ 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