* 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
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Bruno Harbulot @ 2009-10-15 17:23 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <32541b130910141126u4df7f439i3d2926c2e1db9497@mail.gmail.com>
Hello,
Avery Pennarun wrote:
> On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> Avery Pennarun <apenwarr@gmail.com> wrote:
>>> I've been thinking about this myself for some time. One option that
>>> might be "interesting" would be to just grab the *entire* svn tree
>>> (from the root), and then use git-subtree[1] to slice and dice it into
>>> branches using your local copy of git (which is fast and uses no
>>> bandwidth) instead of during the svn fetch (which is slow and uses
>>> lots of bandwidth). I think it would also simplify the git-svn code
>>> quite a lot, at least for fetching, since there would always be a
>>> global view of the tree and SVN things like "copy branch A to tag B"
>>> would just be exactly that.
>> This was actually the original use case of git svn back when I started.
>>
>> git svn clone SVNREPO_ROOT (without --stdlayout)
>>
>> It's still an option if you have the disk space for the working copies,
>> but I had to create the branches/tags support since the working copies
>> would be become prohibitively large. If git-subtree could be
>> taught to work on a bare repo (git svn has a --no-checkout option)
>> it might be an option, too.
Thank you for your suggestions. Unfortunately, I'm not really familiar
with git-subtree and how it could work with git-svn, sorry.
I've tried another workaround: using svnsync to pull the repository only
once, and only then using git-svn fetch, locally, so as to avoid too
much network traffic (I don't mind too much if it loops locally). I was
hoping to be able to change the URL of the repository to the original
one afterwards, but it doesn't seem to work so easily, because of the
commit IDs. I'm assuming not having the same will cause problems for
further fetches (this time directly from the original SVN repository)
and for potential dcommits.
When I do this:
git init
git svn init -s --prefix=svn/ file:///path/to/local/restlet-svnroot
git svn fetch -r 1:2
I get this ID, for example:
r2 = c69a0b98d288a6e4e8779b50962b7fc65c4622e8
If I do this using the original http://restlet.tigris.org/svn/restlet, I
get this:
r2 = ce3b82915e92fe1ccf6ddedacd9d74b30bd4de86
I've even tried to install a Apache-based subversion server locally and
make it believe it was restlet.tigris.org (by editing /etc/hosts and
creating the appropriate VirtualHost), but this generates another SHA1
ID. (That's of course not a solution that would be generalisable.)
I've had a quick look at the git-svn code to see how this ID was
generated, but couldn't find anything obvious.
I realise this isn't the cleanest approach possible, but any suggestion
would be appreciated.
Best wishes,
Bruno.
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: B Smith-Mannschott @ 2009-10-15 17:29 UTC (permalink / raw)
To: Bruno Harbulot; +Cc: git, Eric Wong
In-Reply-To: <4AD75A93.9050106@manchester.ac.uk>
On Thu, Oct 15, 2009 at 19:23, Bruno Harbulot
<Bruno.Harbulot@manchester.ac.uk> wrote:
> Hello,
>
> Avery Pennarun wrote:
>>
>> On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong <normalperson@yhbt.net> wrote:
>>>
>>> Avery Pennarun <apenwarr@gmail.com> wrote:
>>>>
>>>> I've been thinking about this myself for some time. One option that
>>>> might be "interesting" would be to just grab the *entire* svn tree
>>>> (from the root), and then use git-subtree[1] to slice and dice it into
>>>> branches using your local copy of git (which is fast and uses no
>>>> bandwidth) instead of during the svn fetch (which is slow and uses
>>>> lots of bandwidth). I think it would also simplify the git-svn code
>>>> quite a lot, at least for fetching, since there would always be a
>>>> global view of the tree and SVN things like "copy branch A to tag B"
>>>> would just be exactly that.
>>>
>>> This was actually the original use case of git svn back when I started.
>>>
>>> git svn clone SVNREPO_ROOT (without --stdlayout)
>>>
>>> It's still an option if you have the disk space for the working copies,
>>> but I had to create the branches/tags support since the working copies
>>> would be become prohibitively large. If git-subtree could be
>>> taught to work on a bare repo (git svn has a --no-checkout option)
>>> it might be an option, too.
>
> Thank you for your suggestions. Unfortunately, I'm not really familiar with
> git-subtree and how it could work with git-svn, sorry.
>
> I've tried another workaround: using svnsync to pull the repository only
> once, and only then using git-svn fetch, locally, so as to avoid too much
> network traffic (I don't mind too much if it loops locally). I was hoping to
> be able to change the URL of the repository to the original one afterwards,
> but it doesn't seem to work so easily, because of the commit IDs. I'm
> assuming not having the same will cause problems for further fetches (this
> time directly from the original SVN repository) and for potential dcommits.
>
> When I do this:
> git init
> git svn init -s --prefix=svn/ file:///path/to/local/restlet-svnroot
> git svn fetch -r 1:2
>
> I get this ID, for example:
> r2 = c69a0b98d288a6e4e8779b50962b7fc65c4622e8
>
> If I do this using the original http://restlet.tigris.org/svn/restlet, I get
> this:
> r2 = ce3b82915e92fe1ccf6ddedacd9d74b30bd4de86
>
>
> I've even tried to install a Apache-based subversion server locally and make
> it believe it was restlet.tigris.org (by editing /etc/hosts and creating the
> appropriate VirtualHost), but this generates another SHA1 ID. (That's of
> course not a solution that would be generalisable.)
>
> I've had a quick look at the git-svn code to see how this ID was generated,
> but couldn't find anything obvious.
> I realise this isn't the cleanest approach possible, but any suggestion
> would be appreciated.
When I 'git svn clone' from a svnsync mirror I pass
--use-svnsync-props. Have you tried that?
// Ben
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Jeff King @ 2009-10-15 17:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091015165228.GO10505@spearce.org>
On Thu, Oct 15, 2009 at 09:52:28AM -0700, Shawn O. Pearce wrote:
> > 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?
Sure, it is obviously something that an implementation will have to deal
with. Either through manual configuration by the user or some
auto-detection magic that tries to cover every case (and I suspect if we
really wanted to do this, a patch to libcurl to handle different cookie
jar formats would probably be the best way to go).
But my main point was that it is an implementation issue, not a protocol
issue. The lines are a little blurry for us because there really aren't
very many git implementations, but I think your document is an attempt
to document just the protocol to allow interoperability between clients.
But I think you got my point:
> 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.
I think this is a good compromise. It's not recommended at this point,
but there is no reason to disallow it if both sides can handle the
non-protocol part (i.e., storing and managing cookies). Thanks.
-Peff
^ permalink raw reply
* Re: How does format-patch determine the filename of the patch?
From: Thomas Rast @ 2009-10-15 17:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <ed82fe3e0910150917u72ef189epc74411e71a9cd2d4@mail.gmail.com>
Timur Tabi wrote:
> 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?
get_patch_filename() in log-tree.c, but the bulk of the work is done
in the call out to format_commit_message() [pretty.c] with the "%f"
format, which is in turn handled by format_sanitized_subject()
[pretty.c].
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* git am can't import patches with the UTF8 BOM
From: Ondrej Certik @ 2009-10-15 17:51 UTC (permalink / raw)
To: Git Mailing List
Hi,
this happens to me very often when someone sends a patch using windows
(and I use linux):
$ git am ~/Desktop/0001-1664-nonsymbolic-systems-may-need-basis-recalculatio.patch
Patch format detection failed.
and the problem is that the patch contains the byte-order mark (BOM)
at the beginning:
$ hexdump -C ~/Desktop/0001-1664-nonsymbolic-systems-may-need-basis-recalculatio.patch
| less
00000000 ef bb bf 46 72 6f 6d 20 39 31 37 63 30 39 36 32 |...From 917c0962|
00000010 32 38 35 30 37 37 31 66 38 33 33 62 35 66 39 34 |2850771f833b5f94|
00000020 30 36 65 30 64 65 37 33 30 35 61 34 30 38 66 65 |06e0de7305a408fe|
00000030 20 4d 6f 6e 20 53 65 70 20 31 37 20 30 30 3a 30 | Mon Sep 17 00:0|
00000040 30 3a 30 30 20 32 30 30 31 0a 46 72 6f 6d 3a 20 |0:00 2001.From: |
e.g. it's the "ef bb bf" as can be checked on the wikipedia:
http://en.wikipedia.org/wiki/Byte-order_mark#Representations_of_byte_order_marks_by_encoding
for utf-8.
So either the windows version of git should not send the BOM in the
first place, or the linux version of git should be able to handle it.
Which of those should be fixed?
Thanks,
Ondrej
P.S. I currently use this simple python script to strip it:
------------------------
#!/usr/bin/python
"""
Fixes a bogus git patch.
Sometimes a patch that people submit to sympy contains the UTF-8 byte-order
mark (BOM), which are 3 character at the beginning, that cause "git am" to fail
when applying it. The solution is to remove them, which is the purpose of this
script. See this link for more info:
http://en.wikipedia.org/wiki/Byte-order_mark
Usage:
git-fix-patch some.patch > some_fixed.patch
you can also rewrite the original file with the fix (inplace) by:
git-fix-patch -s some.patch
"""
from textwrap import fill
import os
import re
from optparse import OptionParser
def main():
parser = OptionParser(usage="[options] args")
parser.add_option("-s", "--save", dest="save", action="store_true",
default=False,
help="Rewrite the original file with the fixed patch")
options, args = parser.parse_args()
if len(args) != 1:
parser.print_help()
return
filename = args[0]
s = open(filename).read()
start = s.find("From")
if start > 10:
raise Exception("Uknown format of the git patch")
# strip the bogus characters at the beginning of the file
s = s[start:]
# either save to a file or dump to stdout:
if options.save:
outfile = filename
open(outfile, "w").write(s)
else:
print s
if __name__ == '__main__':
main()
-----------------------
^ permalink raw reply
* Re: How does format-patch determine the filename of the patch?
From: Robin Rosenberg @ 2009-10-15 17:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <ed82fe3e0910150917u72ef189epc74411e71a9cd2d4@mail.gmail.com>
torsdag 15 oktober 2009 18:17:09 skrev Timur Tabi:
> 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.
It tells you the names on stdout.
-- robin
^ permalink raw reply
* Re: [PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-15 18:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <200910151341.36520.jnareb@gmail.com>
Jakub Narebski wrote:
>
> 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.)?
A title sounds good. Something like "List commits by $author"? I'll try
to write something up by tonight.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-15 18:51 UTC (permalink / raw)
To: James Pickens
Cc: Jeff King, Junio C Hamano, Daniel Barkalow, 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.
I agree.
> Checking out anything other than a plain ref would still detach the
> head, and commits on a detached head would still be allowed. 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
Nah. This is obnoxious. The usual "this is not a local branch" warning
could be displayed at that point, and if one really ignores the warning
then any commit made that way is always reachable through the reflog.
You would have had to work a bit harder to detach HEAD already anyway,
so at that point you're not supposed to be such a newbie anymore.
> 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.
It is indeed simpler. It makes the checkout command less verbose as
well. Only the commit command would need to warn the user and only if a
forbidden operation is attempted (like committing on a non
refs/heads/*). I think I like this.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-15 19:03 UTC (permalink / raw)
To: Jakub Narebski
Cc: James Pickens, Jeff King, Junio C Hamano, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <m3bpk8g6nj.fsf@localhost.localdomain>
On Thu, 15 Oct 2009, Jakub Narebski wrote:
> James Pickens <jepicken@gmail.com> writes:
>
> > 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.)
I don't think detached head is scary at all (unless viewed in another
context other than git) but if that encounter can be kept away from most
users without denying its use then all for the better.
> 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).
I do like and actively use manual committing on a detached HEAD as well,
so please let's not forget about that use case.
> 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
> # ...
Sure.
> $ 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]":
... or the current "this is not a local branch -- use checkout -b to
create one" warning, just like what we have today when checking out a
tag or remote branch, except that the warning is deferred to the commit
operation which in fact might even not take place.
> 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.
I wouldn't go too far in that direction though. Too many suggestions
would simply bring back confusion to the new user who at that point
might not even understand yet what all the different concepts are.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-15 19:07 UTC (permalink / raw)
To: Daniel Barkalow
Cc: James Pickens, Jeff King, Junio C Hamano, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910151054190.32515@iabervon.org>
On Thu, 15 Oct 2009, Daniel Barkalow wrote:
> 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)
I think this is wrong. Git has multiple heads, and insisting on "not at
head" would be extremely confusing.
Nicolas
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-15 19:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: James Pickens, Jeff King, Junio C Hamano, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910151504510.20122@xanadu.home>
On Thu, 15 Oct 2009, Nicolas Pitre wrote:
> On Thu, 15 Oct 2009, Daniel Barkalow wrote:
>
> > 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)
>
> I think this is wrong. Git has multiple heads, and insisting on "not at
> head" would be extremely confusing.
Maybe "(not at a head)"? Git does have multiple heads, but what's checked
out isn't one of them, and that's actually the point.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-15 19:31 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 origin/master
$ git fetch
$ git checkout origin/next
Uncommited file '...' would be overwritten.
If HEAD is a symref to refs/remotes/origin/master, and you update
refs/remotes/origin/master, git will subsequently see that your index
doesn't match HEAD, and when you switch branches, it will try to apply a
revert to the branch you're switching to. It's the same issue as pushing
into a non-bare repository.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-15 19:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: James Pickens, Jeff King, Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.LFD.2.00.0910151436180.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> It is indeed simpler. It makes the checkout command less verbose as
> well. Only the commit command would need to warn the user and only if a
> forbidden operation is attempted (like committing on a non
> refs/heads/*). I think I like this.
I like James's suggestion to allow us to store refs other than refs/heads/
in HEAD to denote this state, and keep commit and reset from updating such
a ref through updating HEAD.
We have code to prevent HEAD from pointing at anywhere outside refs/heads/
and that may even be an isolated single codepath we need to tweak. But I
am reasonably sure that the layers above these core-level routines have
their own checks to make sure HEAD is either detached or points at
refs/heads/ somewhere; we would need to identify and change them as well.
Also things like "git branch" need to be told that HEAD may point outside
of refs/heads/ now to adjust their output style accordingly. They may
probably strip refs/heads/ (or 11 bytes) assuming that attached HEAD will
never point outside the local branch hierarchy.
So I expect there will be tons of tiny fallouts from a change like that,
but still it is conceptually simpler, and it would reduce the scope of
detached HEAD to a temporary state that is not even worth being named with
a branch name, which is exactly what it is.
^ permalink raw reply
* Re: [PATCH v3] git-gui: adjust the minimum height of diff pane for shorter screen height
From: Junio C Hamano @ 2009-10-15 19:57 UTC (permalink / raw)
To: Vietor Liu; +Cc: Shawn O. Pearce, git, Johannes Schindelin
In-Reply-To: <1255583127-14893-1-git-send-email-vietor@vxwo.org>
Vietor Liu <vietor@vxwo.org> writes:
> When the screen height is shorter (e.g. Netbook screen 1024x600), both the
> partial commit pane and the status bar will hide. This patch adjust the
> minimum height of the diff pane, allowing the overall window to be shorter
> and still display both the entire commit pane and status bar.
Ah, I finally can parse and understand what this s/15/5/ change was about
;-). Perhaps with "s/will hide/are hidden/" it would be perfect?
>
> Signed-off-by: Vietor Liu <vietor@vxwo.org>
> ---
> git-gui.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-gui.sh b/git-gui.sh
> index 09b2720..037a1f2 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
> set ui_diff .vpane.lower.diff.body.t
> text $ui_diff -background white -foreground black \
> -borderwidth 0 \
> - -width 80 -height 15 -wrap none \
> + -width 80 -height 5 -wrap none \
> -font font_diff \
> -xscrollcommand {.vpane.lower.diff.body.sbx set} \
> -yscrollcommand {.vpane.lower.diff.body.sby set} \
> --
> 1.6.5
>
> --
> 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
^ permalink raw reply
* Re: My custom cccmd
From: Junio C Hamano @ 2009-10-15 20:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530910150620g733bdf0aq88660053f869b0a9@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> 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
Comments.
#0. Gaahhh, my eyes, my eyes!! Can't you do this ugly run of infinite
number of "end"s?
#1. You are not making sure that you start blaming from the commit the
patch is based on, so your -La,b line numbers can be off. If you can
assume that you are always reading format-patch output, you can learn
which commit to start from by reading the first "magic" line.
#2. If you have two patch series that updates one file twice, some
changes in your second patch could even be an update to the changes
you introduced in your first patch. After you fix issue #1, you
would probably want to fix this by excluding the commits you have
already sent the blames for.
#3. Does the number of commits you keep per author have any significance?
I know it doesn't in the implementation you posted, but should it,
and if so how?
> @commits.each_key do |a|
> puts a
> end
>
> --
> Felipe Contreras
> --
> 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
^ 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