* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Junio C Hamano @ 2009-10-15 7:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255577814-14745-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> This v3 series is a respin, and includes fixes to address reviewer
> comments from v2.
Thanks.
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-15 7:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Junio C Hamano, Andy Isaacson, git
In-Reply-To: <alpine.LFD.2.00.0910141435040.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> I confirm this test without the fix reproduces the infinite loop (and
> does stall the test suite).
Thanks, both of you.
^ permalink raw reply
* Q: how to check for -crlf property for a set of files using git command line?
From: Constantine Plotnikov @ 2009-10-15 9:15 UTC (permalink / raw)
To: Git Mailing List
Hello!
I'm interested how to check for -crlf property (from .gitattributes)
on the set of files using git command line. I'm also interested how to
query for values specified in .gitattributes in general from scripts.
Parsing .gitattributes looks like too complex way of doing this.
Constantine
^ permalink raw reply
* Re: Q: how to check for -crlf property for a set of files using git command line?
From: Johannes Sixt @ 2009-10-15 9:25 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Git Mailing List
In-Reply-To: <85647ef50910150215w1efec91fu16b1fe13f8acec61@mail.gmail.com>
Constantine Plotnikov schrieb:
> I'm interested how to check for -crlf property (from .gitattributes)
> on the set of files using git command line. I'm also interested how to
> query for values specified in .gitattributes in general from scripts.
> Parsing .gitattributes looks like too complex way of doing this.
man git-check-attr
-- Hannes
^ permalink raw reply
* Re: why no "ignore" command on git
From: Johannes Schindelin @ 2009-10-15 9:29 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: Ralf Thielow, git
In-Reply-To: <200910142220.51725.wjl@icecavern.net>
Hi,
On Wed, 14 Oct 2009, Wesley J. Landaker wrote:
> On Wednesday 14 October 2009 16:35:23 Ralf Thielow wrote:
> > why does git don't have an "ignore" command, to ignore some files or
> > directories all the time.
> [...]
> > I read on some pages by a google search that you can create
> > a ".gitignore" directory or something like that. But you had to do
> > this manually.
> >
> > why there is no "ignore" command on git?
>
> You could always make your own git-ignore script, e.g.:
>
> #!/bin/sh
> echo "$@" >> .gitignore
Probably it needs to be a little more sophisticated, because of Postel's
law.
#!/bin/sh
git rev-parse > /dev/null || exit
for f
do
case "$f" in
*'[*?]'*)
# patterns probably are meant to be recursive
echo "$f"
;;
*)
echo /"$f"
;;
esac >> .gitignore
done
git add .gitignore
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Nanako Shiraishi @ 2009-10-15 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7v63ah85ss.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> This v3 series is a respin, and includes fixes to address reviewer
>> comments from v2.
>
> Thanks.
Junio, you merged this series to your "pu" branch, but it breaks "make test" (t9801). Shawn's "sp/smart-http" topic doesn't have t9801 and passes all the tests.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* unrelated file conflict during rebase
From: bill lam @ 2009-10-15 10:35 UTC (permalink / raw)
To: git
Something I change a file in rebase -i. During the process, for some
commits, git said some other apparently unrelated files (not that I
had changed) caused merged conflicts usually both modified. Why did
this happen?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: submodule-summary
From: Jens Lehmann @ 2009-10-15 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vskdla98f.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> I am _not_ married to the naming "shortlog", by the way, and shortlog is
> rather a bad name for it. Sorry for suggesting it; it is quite different
> from the actual "git shortlog" command output (and no I am not suggesting
> to make the output similar to shortlog), but rather is more similar to
> "log --left-right --oneline". But I think you got the point.
I have no strong feelings about the option names either. What about
"--submodule=short" for the current default git diff output and
"--submodule=left-right-log" for the one resembling the current output
of submodule summary? I really don't know, if there are better proposals
i'll happily use them.
^ permalink raw reply
* Re: why no "ignore" command on git
From: Matthieu Moy @ 2009-10-15 11:31 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: Ralf Thielow, git
In-Reply-To: <200910142220.51725.wjl@icecavern.net>
"Wesley J. Landaker" <wjl@icecavern.net> writes:
> On Wednesday 14 October 2009 16:35:23 Ralf Thielow wrote:
>> why does git don't have an "ignore" command, to ignore some files or
>> directories all the time.
> [...]
>> I read on some pages by a google search that you can create
>> a ".gitignore" directory or something like that. But you had to do
>> this manually.
>>
>> why there is no "ignore" command on git?
>
> You could always make your own git-ignore script, e.g.:
>
> #!/bin/sh
> echo "$@" >> .gitignore
Sure. OTOH, there are other interesting things a "ignore" command can
do. bzr, for example, has a "bzr ignore" command that can either add
stuff to your .bzrignore, or tell you which pattern cause which file
to be ignored. That's handy sometimes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] gitweb: linkify author/committer names with search
From: Jakub Narebski @ 2009-10-15 11:41 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
On Wed, 14 Oct 2009, Stephen Boyd wrote:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
[...]
I see that it can be useful. But is this discoverable, and does this
do expected thing? Most of links in gitweb lead to some view (page)
that is specific to link; other lead to anchor on same page. Leading
to search results can be unexpected.
Perhaps title explaining what does such link does would help? Or making
style of this link distinct from other (dashed underline, dashed
underline on mouseover, double underline, different mouse cursor on
mouseover, etc.)?
Just my 2 eurocents. Feel free to ignore my ramblings.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: quote in help code example
From: Thomas Rast @ 2009-10-15 12:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bill lam, git
In-Reply-To: <200910132215.46840.trast@student.ethz.ch>
Thomas Rast wrote:
>
> The patch below just replaces said template with a no-op for git's
> manpage creation. I have not been able to substantiate the claim that
> apostrophes are special, and in fact with the patch my manpages look
> fine. Then again I don't know anything about roff syntax either, and
> manuals seem a bit hard to come by.
Actually, scratch the patch. I haven't been able to nail it yet, and
I'm not sure I have the energy for another stab at this mess; but
during testing with older versions, I learned that they behave
differently and the patch just shifts the breakage a bit.
Also, the single quotes are apparently special at the beginning of a
line and to delimit function arguments, though not elsewhere. The
bash manpage uses \(aq to get a literal apostrophe, which I will aim
to convert them to. Oddly enough, the groff(7) manpage does not
document \(aq, but lists \(cq as the official escape for ' ... which
then turns out to mutate into this cursed non-apostrophe again. Sigh.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jakub Narebski @ 2009-10-15 12:54 UTC (permalink / raw)
To: James Pickens
Cc: Jeff King, Junio C Hamano, Nicolas Pitre, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <885649360910150036o72c3bd97ofad85d5316dc5b35@mail.gmail.com>
James Pickens <jepicken@gmail.com> writes:
> How about not detaching the head at all if the user checks out any ref, and
> reject commits if he checked out a tag or remote branch. For example:
>
> $ git checkout origin/master
> $ git status
> # On branch origin/master
> $ git commit ;# complain
>
> $ git checkout v1.0.1
> $ git status
> # On tag v1.0.1
> $ git commit ;# complain
>
> $ git checkout v1.0.1^0 ;# detach
> $ git commit ;# ok
>
> I think this would help the newbies and wouldn't cost the experts too much.
> Checking out anything other than a plain ref would still detach the head, and
> commits on a detached head would still be allowed.
I think it is a very good idea.
This makes it easy to checkout remote-tracking branch or a tag for
viewing, something that was (I think) one of problems (use cases) that
lead to invention of detached HEAD... and then it turned out that
detached HEAD (unnamed branch) is scary for newbie git users. (So the
difficulty of having to create new branch or rewind some branch to
view non-committable ref was replaced by scary detached HEAD concept.)
With this idea there are no problems with git commands that use
detached HEAD such as git-bisect (which uses it in viewing mode, but
then skips through history, so detached HEAD is a good solution here)
or git-rebase (which does committing on detached HEAD for easier
aborting and cleanup).
Let me propose additional feature: "smart" (context sensitive)
warnings, namely that in the following sequence
$ git checkout origin/master
$ git status
# On remote-tracking branch origin/master of remote origin
# ...
$ git commit
'git commit' would refuse committing on non-heads ref, and propose,
beside _always_ proposing detaching HEAD and committing on such
detached HEAD (unnamed branch) via "git checkout HEAD^0", or
"git checkout --detach [HEAD]":
1. If there is no local branch which follows 'origin/master'
(which has 'origin/master' as upstream, which tracks 'origin/master')
propose creating it before comitting:
$ git checkout -t origin/master
2. If there is single local branch that follows 'origin/master',
and it fast-forwards to 'origin/master' propose...
errr, something that would mean fast-forwarding this branch
and making a commit on local branch that has 'origin/master'
as upstream.
3. If there is single local branch that follows 'origin/master', but
it has changes / diverges from 'origin/master' we are viewing,
propose... hmmm, what then?
4. If there are more than one local branch that has 'origin/master'
as upstream, list all those branches in message.
> Perhaps as an additional safety feature, Git could refuse to switch
> away from a detached head if the head isn't reachable from any ref,
> and require -f to override:
>
> $ git checkout $sha1
> $ git commit
> $ git checkout master ;# complain
> $ git checkout -f master ;# ok
>
> Maybe I'm missing something and this all can't be done, but it seems simpler
> than the other options I've seen in this thread.
I'm not sure about overloading '-f' option, unless we would require
doubled '-f' for overriding both safety checks: checkout from detached
HEAD, and current meaning of forcing a switch even if index or the
working are differs from HEAD. So you would need
$ git checkout -f -f master
if you are on detached HEAD and have uncommitted changes (dirty tree
or dirty index).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* My custom cccmd
From: Felipe Contreras @ 2009-10-15 13:20 UTC (permalink / raw)
To: git
Hi,
I love the new option to run a cccmd and how good it works on the
linux kernel, but I couldn't find a generic script. So I decided to
write my own.
It's very simple, it just looks into the authors of the commits that
modified the lines being overridden (git blame). It's not checking for
s-o-b, or anything fancy.
Comments?
#!/usr/bin/env ruby
@commits = {} # keeps a count of commits per author
ARGV.each do |filename|
File.open(filename) do |patch_file|
patch_file.each_line do |patch_line|
case patch_line
when /^---\s+(\S+)/
@source = $1[2..-1]
when /^@@\s-(\d+),(\d+)/
blame = `git blame -p -L #{$1},+#{$2} #{@source} | grep author`
blame.each_line do |al|
key, value = al.chomp.split(" ", 2)
case key
when "author"
@name = value
when "author-mail"
@mail = value
author = "\"#{@name}\" #{@mail}"
@commits[author] ||= 0
@commits[author] += 1
end
end
end
end
end
end
@commits.each_key do |a|
puts a
end
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-15 14:11 UTC (permalink / raw)
To: Jakub Narebski
Cc: James Pickens, Jeff King, Junio C Hamano, Nicolas Pitre,
Daniel Barkalow, Jay Soffian, git
In-Reply-To: <m3bpk8g6nj.fsf@localhost.localdomain>
On 2009.10.15 05:54:52 -0700, Jakub Narebski wrote:
> James Pickens <jepicken@gmail.com> writes:
> > Perhaps as an additional safety feature, Git could refuse to switch
> > away from a detached head if the head isn't reachable from any ref,
> > and require -f to override:
> >
> > $ git checkout $sha1
> > $ git commit
> > $ git checkout master ;# complain
> > $ git checkout -f master ;# ok
> >
> > Maybe I'm missing something and this all can't be done, but it seems simpler
> > than the other options I've seen in this thread.
>
> I'm not sure about overloading '-f' option, unless we would require
> doubled '-f' for overriding both safety checks: checkout from detached
> HEAD, and current meaning of forcing a switch even if index or the
> working are differs from HEAD. So you would need
>
> $ git checkout -f -f master
>
> if you are on detached HEAD and have uncommitted changes (dirty tree
> or dirty index).
A dirty index/worktree doesn't necessarily stop you from checking out a
different branch head/commit. Only if you have uncommitted changes to a
file that also has changes between HEAD and <other_branch>, git refuses
to switch. And if you want to keep your uncommitted changes, you want to
use -m (3-way merge), not -f (drop changes).
git checkout -f foo ~= git reset --hard && git checkout foo
So -f is most likely _not_ the flag one wants to overload.
Björn
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-15 14:33 UTC (permalink / raw)
To: Nanako Shiraishi, Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <20091015185253.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >> This v3 series is a respin, and includes fixes to address reviewer
> >> comments from v2.
>
> Junio, you merged this series to your "pu" branch, but it breaks
> "make test" (t9801). Shawn's "sp/smart-http" topic doesn't have
> t9801 and passes all the tests.
Actually, pu contains v2 right now, not v3.
And pu doesn't always pass the tests... because of issues like this.
It looks like there might be a semantic clash between John Herland's
jh/cvs-helper branch and my sp/smart-http branch... but digging
around at the code I haven't quite identified what that might be.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Johan Herland @ 2009-10-15 15:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <20091015143340.GI10505@spearce.org>
On Thursday 15 October 2009, Shawn O. Pearce wrote:
> Nanako Shiraishi <nanako3@lavabit.com> wrote:
> > > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > >> This v3 series is a respin, and includes fixes to address
> > >> reviewer comments from v2.
> >
> > Junio, you merged this series to your "pu" branch, but it breaks
> > "make test" (t9801). Shawn's "sp/smart-http" topic doesn't have
> > t9801 and passes all the tests.
>
> Actually, pu contains v2 right now, not v3.
>
> And pu doesn't always pass the tests... because of issues like this.
>
> It looks like there might be a semantic clash between John Herland's
> jh/cvs-helper branch and my sp/smart-http branch... but digging
> around at the code I haven't quite identified what that might be.
Don't have time to look into this at the moment, but a cursory gdb
shows that the "git fetch" in test #4 in t9801 segfaults with the
following stacktrace:
#0 0x00007f8dd67e8a47 in fclose () from /lib/libc.so.6
#1 0x00000000004a05b5 in disconnect_helper (transport=<value optimized out>) at transport-helper.c:81
#2 0x000000000049de1e in transport_disconnect (transport=0x1955490) at transport.c:952
#3 0x0000000000423477 in cmd_fetch (argc=26566704, argv=0x0, prefix=<value optimized out>) at builtin-fetch.c:748
#4 0x0000000000404233 in handle_internal_command (argc=2, argv=0x7fffdf293d20) at git.c:251
#5 0x0000000000404426 in main (argc=2, argv=0x7fffdf293d20) at git.c:438
Don't know if this helps...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-15 15:36 UTC (permalink / raw)
To: James Pickens; +Cc: Jeff King, Junio C Hamano, Nicolas Pitre, Jay Soffian, git
In-Reply-To: <885649360910150036o72c3bd97ofad85d5316dc5b35@mail.gmail.com>
On Thu, 15 Oct 2009, James Pickens wrote:
> On Wed, Oct 14, 2009 at 4:09 PM, Jeff King <peff@peff.net> wrote:
> > That makes the most sense to me. If "git checkout" could write metadata
> > into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout
> > could record an "ok to commit" bit. And could also be used to change it
> > after the fact. E.g.:
> >
> > $ git checkout --detach=commit origin/master
> > $ git commit ;# should be ok
> >
> > $ git checkout --detach=examine origin/master
> > $ git commit ;# complain
> > $ git checkout --detach=commit HEAD
> > $ git commit ;# ok
> >
> > I guess something like "rebase" should detach with "ok to commit", since
> > it is planning on attaching the commits later. I'm not sure about "git
> > bisect". I guess probably it should be "not ok to commit" to be on the
> > safe side, and then somebody can "git checkout --detach=commit" if they
> > want to.
>
> How about not detaching the head at all if the user checks out any ref, and
> reject commits if he checked out a tag or remote branch. For example:
>
> $ git checkout origin/master
> $ git status
> # On branch origin/master
> $ git commit ;# complain
>
> $ git checkout v1.0.1
> $ git status
> # On tag v1.0.1
> $ git commit ;# complain
>
> $ git checkout v1.0.1^0 ;# detach
> $ git commit ;# ok
>
> I think this would help the newbies and wouldn't cost the experts too much.
> Checking out anything other than a plain ref would still detach the head, and
> commits on a detached head would still be allowed.
I think reducing users' exposure to the "detached HEAD" state would just
make it take longer for them to find that state familiar.
It's not like the concept is actually very difficult or unusual. CVS has
it as "cvs checkout -r <something>" or "cvs checkout -D <something>"; SVN
has it as "svn checkout -r <something>". It was weird and scary in CVS if
you did it (it was "sticky tags", and you had to find a different option
to get back to normal), but SVN is easier ("svn checkout -r HEAD").
I think the description used in CVS and SVN (and, I think, others) is that
you're not at the HEAD revision. I think they both account for the state
where you've checked out the revision by number that's the latest
revision, but you still can't grow the branch because you can't
simultaneously stay on r1000 (as requested explicitly) and add a new
commit.
So maybe the right explanation is:
$ git checkout master; git branch
* master
$ git checkout origin/master; git branch
* origin/master (not at head)
$ git checkout 123cafe^5; git branch
* 123cafe^5 (not at head)
$ git checkout HEAD^2; git branch
* 123cafe^5^2
$ git commit; git branch
* (temporary branch)
Then we can say that one way that git is different from SVN is that all
branches of other repositories are read-only, and you can't be at the
head when you're on them (because the head of those branches are in
different repositories); instead you grow the history locally, and you
tell the remote branch to adopt your history.
> Perhaps as an additional safety feature, Git could refuse to switch away
> from a detached head if the head isn't reachable from any ref
As far as I know, people don't actually seem to lose stuff this way. In
part, that's because they get scared before they get there; in part,
that's because they just don't think to go there; and in part, we tell
them how to recover stuff at that point (using the ref log or the sha1).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-15 15:41 UTC (permalink / raw)
To: Johan Herland; +Cc: Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <200910151721.08352.johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> Don't have time to look into this at the moment, but a cursory gdb
> shows that the "git fetch" in test #4 in t9801 segfaults with the
> following stacktrace:
>
> #0 0x00007f8dd67e8a47 in fclose () from /lib/libc.so.6
> #1 0x00000000004a05b5 in disconnect_helper (transport=<value optimized out>) at transport-helper.c:81
> #2 0x000000000049de1e in transport_disconnect (transport=0x1955490) at transport.c:952
> #3 0x0000000000423477 in cmd_fetch (argc=26566704, argv=0x0, prefix=<value optimized out>) at builtin-fetch.c:748
> #4 0x0000000000404233 in handle_internal_command (argc=2, argv=0x7fffdf293d20) at git.c:251
> #5 0x0000000000404426 in main (argc=2, argv=0x7fffdf293d20) at git.c:438
It does. It is caused by the disconnect_helper call inside of
fetch_with_import. You can't disconnect inside of the fetch method
of a transport, the caller is going to disconnect you a second time.
During that second disconnect the transport->data field is now
pointing at a garbage area of memory. We're passing a garbage
pointer from data->out to fclose, and fclose is rightly upset.
This bug isn't due to the merge, its a bug in Johan's series that
needs to be fixed before it could merge down to next/master.
--
Shawn.
^ permalink raw reply
* Re: why no "ignore" command on git
From: Jeff King @ 2009-10-15 15:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Wesley J. Landaker, Ralf Thielow, git
In-Reply-To: <vpqaazsrj0q.fsf@bauges.imag.fr>
On Thu, Oct 15, 2009 at 01:31:01PM +0200, Matthieu Moy wrote:
> >> why there is no "ignore" command on git?
> >
> > You could always make your own git-ignore script, e.g.:
> >
> > #!/bin/sh
> > echo "$@" >> .gitignore
>
> Sure. OTOH, there are other interesting things a "ignore" command can
> do. bzr, for example, has a "bzr ignore" command that can either add
> stuff to your .bzrignore, or tell you which pattern cause which file
> to be ignored. That's handy sometimes.
I wrote a toy patch that did something like that a while ago:
http://thread.gmane.org/gmane.comp.version-control.git/108671/focus=108842
I don't think there is any reason such a thing could not be included
with git (if it did something more interesting than just echoing its
arguments to .gitignore), but nobody has felt strongly enough about it
yet to actually write something polished.
-Peff
^ permalink raw reply
* How does format-patch determine the filename of the patch?
From: Timur Tabi @ 2009-10-15 16:17 UTC (permalink / raw)
To: git
Hi. I'm not familiar with the git source code, so forgive me if this
is a dumb question. I'm trying to determine the algorithm that
git-format-patch uses to determine the name of the patch file it
creates (e.g. "0001-this-is-my-patch-without-spaces-and-trunca.patch")
I'm looking at the function cmd_format_patch(), and I just don't see
where it creates any files. Can someone show me where this code is?
The reason I ask is that I'm writing a script which calls
git-format-patch to create some patches for post-processing. So I
need the name of the file that git-format-patch creates so that I can
open it and examine it. I'd liked to see if there's a way to get the
name of the patch without actually creating the file.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Michael J Gruber @ 2009-10-15 16:29 UTC (permalink / raw)
To: Daniel Barkalow
Cc: James Pickens, Jeff King, Junio C Hamano, Nicolas Pitre,
Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910151054190.32515@iabervon.org>
Daniel Barkalow venit, vidit, dixit 15.10.2009 17:36:
> On Thu, 15 Oct 2009, James Pickens wrote:
>
>> On Wed, Oct 14, 2009 at 4:09 PM, Jeff King <peff@peff.net> wrote:
>>> That makes the most sense to me. If "git checkout" could write metadata
>>> into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout
>>> could record an "ok to commit" bit. And could also be used to change it
>>> after the fact. E.g.:
>>>
>>> $ git checkout --detach=commit origin/master
>>> $ git commit ;# should be ok
>>>
>>> $ git checkout --detach=examine origin/master
>>> $ git commit ;# complain
>>> $ git checkout --detach=commit HEAD
>>> $ git commit ;# ok
>>>
>>> I guess something like "rebase" should detach with "ok to commit", since
>>> it is planning on attaching the commits later. I'm not sure about "git
>>> bisect". I guess probably it should be "not ok to commit" to be on the
>>> safe side, and then somebody can "git checkout --detach=commit" if they
>>> want to.
>>
>> How about not detaching the head at all if the user checks out any ref, and
>> reject commits if he checked out a tag or remote branch. For example:
>>
>> $ git checkout origin/master
>> $ git status
>> # On branch origin/master
>> $ git commit ;# complain
>>
>> $ git checkout v1.0.1
>> $ git status
>> # On tag v1.0.1
>> $ git commit ;# complain
>>
>> $ git checkout v1.0.1^0 ;# detach
>> $ git commit ;# ok
>>
>> I think this would help the newbies and wouldn't cost the experts too much.
>> Checking out anything other than a plain ref would still detach the head, and
>> commits on a detached head would still be allowed.
>
> I think reducing users' exposure to the "detached HEAD" state would just
> make it take longer for them to find that state familiar.
Yep. Which is why I keep suggesting that git clone does not create any
local branches at all ;)
> It's not like the concept is actually very difficult or unusual. CVS has
> it as "cvs checkout -r <something>" or "cvs checkout -D <something>"; SVN
> has it as "svn checkout -r <something>". It was weird and scary in CVS if
> you did it (it was "sticky tags", and you had to find a different option
> to get back to normal), but SVN is easier ("svn checkout -r HEAD").
svn up -r HEAD
> I think the description used in CVS and SVN (and, I think, others) is that
> you're not at the HEAD revision. I think they both account for the state
> where you've checked out the revision by number that's the latest
> revision, but you still can't grow the branch because you can't
> simultaneously stay on r1000 (as requested explicitly) and add a new
> commit.
I'd say the fundamental difference is that in CVS and SVN, there is
always only one "tip", which they call HEAD. This is also why revision
numbers make sense.
In git and hg there can be many tips (branch heads) from which to grow
the DAG. Heck, you can grow a new one from any commit ;)
> So maybe the right explanation is:
>
> $ git checkout master; git branch
> * master
> $ git checkout origin/master; git branch
> * origin/master (not at head)
Ouch, please don't. HEAD has a completely different meaning in git. I
know you know, of course.
> $ git checkout 123cafe^5; git branch
> * 123cafe^5 (not at head)
> $ git checkout HEAD^2; git branch
> * 123cafe^5^2
> $ git commit; git branch
> * (temporary branch)
>
> Then we can say that one way that git is different from SVN is that all
> branches of other repositories are read-only, and you can't be at the
> head when you're on them (because the head of those branches are in
> different repositories); instead you grow the history locally, and you
> tell the remote branch to adopt your history.
You can change your refs/remotes/origin/master, of course, it's just by
convention (for a good reason) that git treats them as read-only, and
porc. respects that.
git's branches are simply completely different, they're movable tags,
and I think that's one point new users *have* to grok. Once they're over
this then even detached heads are a natural thing.
>> Perhaps as an additional safety feature, Git could refuse to switch away
>> from a detached head if the head isn't reachable from any ref
>
> As far as I know, people don't actually seem to lose stuff this way. In
> part, that's because they get scared before they get there; in part,
> that's because they just don't think to go there; and in part, we tell
> them how to recover stuff at that point (using the ref log or the sha1).
Maybe we just don't scare them enough yet :)
Michael
^ permalink raw reply
* [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
From: Björn Gustavsson @ 2009-10-15 16:39 UTC (permalink / raw)
To: gitster; +Cc: git
Correct the usage text to make it clear that --tags cannot
be combined with --all or --mirror.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..425594a 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror | --tags] [-n | --dry-run] [--porcelain] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
--
1.6.5.2.gd6127
^ permalink raw reply related
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Shawn O. Pearce @ 2009-10-15 16:39 UTC (permalink / raw)
To: Alex Blewitt; +Cc: git
In-Reply-To: <loom.20091009T104530-586@post.gmane.org>
Alex Blewitt <Alex.Blewitt@gmail.com> wrote:
> Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> > +URL Format
> > +----------
>
> It's worth making clear here that $GIT_URL will be the path to the repository,
...
Thanks, noted.
> > HEX = [0-9a-f]
>
> Is there any reason not to support A-F as well in the hex spec, even if they
> SHOULD use a-f?
Consistency. I'd rather be strict and say HEX is [0-9a-f] and
demand that everyone try to standardize on the lower case form.
> This may limit the appeal for some case-insensitive systems.
Given that this particular notation of HEX is *only* used within
the protocol body to describe SHA-1 IDs, it won't make it to the
file system as-is.
A conforming Git implementation would first validate that this is in
fact a SHA-1 ID, likely translate it into a binary representation
(that is collapse the 40 byte hex to a 20 byte binary), and then
reformat it as a file system path if its looking for a loose object.
> It would also be good to document, like with the git daemon, whether all
> repositories under a path are exported or only those that have the magic
> setting in the config like git-daemon-export-ok.
This isn't something that matters to the protocol specification.
Its a server access control, not protocol detail.
Really, its an implementation detail of git-http-backend in git.git,
or of the RepositoryResolver and UploadPackFactory in JGit.
Therefore, its not going to be documented in this document.
> Lastly, it would be good to clarify when the result of this GET/POST exchange
> is a text-based (and encoded in UTF-8) vs when binary data is returned; we
> don't want to get into the state where we're returning binary data and
> pretending that it's UTF-8.
Oh, right.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Shawn O. Pearce @ 2009-10-15 16:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091009195035.GA15153@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Oct 08, 2009 at 10:22:45PM -0700, Shawn O. Pearce wrote:
> > +Servers MUST NOT require HTTP cookies for the purposes of
> > +authentication or access control.
> > [...]
> > +Servers MUST NOT require HTTP cookies in order to function correctly.
>
> Why not? I can grant that the current git implementation probably can't
> handle it, but keep in mind this is talking about the protocol and not
> the implementation.
Good point... this document is about trying to explain the common
functionality that everyone can agree on.
> And I can see it being useful for sites like github
> which already have a cookie-based login.
What I'm concerned about is using the cookie jar. My Mac OS X
laptop has 5 browsers installed, each with their own #@!*! cookie
jar: Safari, Opera, Firefox, Camino, Google Chrome. How the hell
is the git client going to be able to use those cookies in order
to interact with a website that requires cookie authentication?
> Adapting the client to handle
> this case would not be too difficult (it would just mean keeping cookie
> state in a file between runs,
Saving our own cookie jar is easy, libcurl has some limited cookie
jar support already built in. We just have to enable it.
> or even just pulling it out of the normal
> browser's cookie store).
See above, I don't think this will be very easy.
> And people whose client didn't do this would
> simply get an "access denied" response code.
And then they will email git ML or ask on #git why their git client
can't speak to some random website... and its because they used
"lynx" or yet-another-browser whose cookie jar format we can't read.
> Is there a technical reason not to allow it?
Not technical, but I want to reduce the amount of complexity that
a conforming client has to deal with to reduce support costs for
everyone involved.
I weakend the sections on cookies:
+ Authentication
+ --------------
....
+ Servers SHOULD NOT require HTTP cookies for the purposes of
+ authentication or access control.
and that's all we say on the matter. I took out the Servers MUST
NOT line under session state.
--
Shawn.
^ permalink raw reply
* [PATCH] gitk: Add configuration for UI colour scheme (menus, scrollbars, etc)
From: Guillermo S. Romero @ 2009-10-15 16:51 UTC (permalink / raw)
To: git; +Cc: paulus
Add option to control global colour scheme in Edit > Preferences dialog
so the whole interface can have other color beyond the default one
and match changes to other areas controlled by bgcolor and fgcolor.
Signed-off-by: Guillermo S. Romero <gsromero@infernal-iceberg.com>
---
Hi:
Small cosmetic patch. I found all colours were easily configurable
from prefs, except the main colour, which can look a bit out of place
with the rest. No big changes, Tk computes all needed colours for
button shading, fonts, etc. I hope the patch is correct, first time
with git.
Thanks for the app, pretty useful.
GSR
PS: Not subscribed to git@vger, so remember to CC: me.
gitk-git/gitk | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..d40a735 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2519,7 +2519,7 @@ proc savestuff {w} {
global maxwidth showneartags showlocalchanges
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
- global colors bgcolor fgcolor diffcolors diffcontext selectbgcolor
+ global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
global autoselect extdifftool perfile_attrs markbgcolor
global hideremotes
@@ -2546,6 +2546,7 @@ proc savestuff {w} {
puts $f [list set showlocalchanges $showlocalchanges]
puts $f [list set datetimeformat $datetimeformat]
puts $f [list set limitdiffs $limitdiffs]
+ puts $f [list set uicolor $uicolor]
puts $f [list set bgcolor $bgcolor]
puts $f [list set fgcolor $fgcolor]
puts $f [list set colors $colors]
@@ -10425,7 +10426,7 @@ proc chg_fontparam {v sub op} {
proc doprefs {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags showlocalchanges
- global bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
+ global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
global tabstop limitdiffs autoselect extdifftool perfile_attrs
global hideremotes
@@ -10489,6 +10490,10 @@ proc doprefs {} {
label $top.cdisp -text [mc "Colors: press to choose"]
grid $top.cdisp - -sticky w -pady 10
+ label $top.ui -padx 40 -relief sunk -background $uicolor
+ button $top.uibut -text [mc "Interface"] -font optionfont \
+ -command [list choosecolor uicolor {} $top.ui [mc "interface"] setui]
+ grid x $top.uibut $top.ui -sticky w
label $top.bg -padx 40 -relief sunk -background $bgcolor
button $top.bgbut -text [mc "Background"] -font optionfont \
-command [list choosecolor bgcolor {} $top.bg [mc "background"] setbg]
@@ -10572,6 +10577,10 @@ proc setselbg {c} {
allcanvs itemconf secsel -fill $c
}
+proc setui {c} {
+ tk_setPalette $c
+}
+
proc setbg {c} {
global bglist
@@ -11079,6 +11088,7 @@ if {[tk windowingsystem] eq "aqua"} {
}
set colors {green red blue magenta darkgrey brown orange}
+set uicolor grey85
set bgcolor white
set fgcolor black
set diffcolors {red "#00a000" blue}
@@ -11130,6 +11140,8 @@ eval font create textfontbold [fontflags textfont 1]
parsefont uifont $uifont
eval font create uifont [fontflags uifont]
+tk_setPalette $uicolor
+
setoptions
# check that we can find a .git directory somewhere...
--
1.6.4.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox