* Re: [PATCH 0/2] History replay support
From: Marco Costalba @ 2007-11-03 7:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <alpine.LFD.0.999.0711021809060.3342@woody.linux-foundation.org>
On 11/3/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 2 Nov 2007, Linus Torvalds wrote:
> >
> > The bad news is that it doesn't work well in this simplistic form, because
> > there is a O(n**2) behaviour when replays *do* happen, ie we end up having
> > replays within replays [..]
>
> Gaah. the more I look at this, the more I think the topo sort should be
> done at the visualization side.
>
> It's really quite cheap to do the topo sort, *and* it's really quite cheap
> to do the tests that trigger the topo sort, but what's expensive is to
> re-output all the data again!
>
> The silly thing is, I think I've come up with an "almost optimal"
> solution, but it's so ugly that I'm a bit ashamed of it.
>
> That almost optimal solution is simply:
> - get the first <n> (say: 100) commits, and topo-sort just them. Feed it
> to the visualizer.
> - the visualizer will now have enough to work with in order to show the
> starting screen and set the cursor to the hourglass or whatever the
> "wait for it" thing is.
> - get the rest of the commits at our normal leisurely pace (whether it
> is one second of 17).
> - output the total number of commits (so that the visualizer can re-size
> the slider and/or allocate some big array just once), topo-sort it all,
> and output the full thing.
>
> It's disgusting. But it avoids the unnecessary data transfer - except for
> just the first 100 commits that get sent twice. And it gets what *I* look
> for, namely that "immediate" feel to the initial pop-up of the history.
>
It's not disgusting is human perception oriented !
All this stuff is not needed to get the sha faster, but to let think
the user that are faster. It's for strictly human consumption, so I
would say your "ugly" solution is the best for me.
A bunch of revisions, just to let user eyes to re-focus on new stuff
(and some hundredths of milliseconds are already elapsed after this)
while in the background the real, shadowed, work goes on.
It's also easy on the client GUI side, simply discard all and reload
as soon _correct_ data arrives.
So the new option could became:
git log --fast-output 100 500 --topo-order <...whatever...>
where git log outputs as soon as it can 100 commits and feeds it to
the visualizer. If the _normal_ commits are still not ready after 500
ms are elapsed then git log spits out another 100 commits chunk and so
on at 500ms intervals until good commits are ready. Then outputs the
full thing.
It is very user perception oriented, but hey, so is a GUI!
Marco
P.S: A little optimization for small repositories would be that git
log *waits* at maximum 500ms before to output the first 100 commits
chunk, so that in case of small repos (thousands of revisions) or in
case of warmed up cache the commits in output are already the good
ones, no need for fakes!
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 8:02 UTC (permalink / raw)
To: Pascal Obry; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <EE16FE19-8C6C-4438-8E6E-EA6B87A898A7@zib.de>
On Nov 3, 2007, at 8:57 AM, Steffen Prohaska wrote:
> On Nov 3, 2007, at 8:19 AM, Pascal Obry wrote:
>
>> Steffen Prohaska a écrit :
>>>> The best Git port on Windows is the Cygwin one. I'm using git-svn
>>>> without trouble.
>>>
>>> But you _MUST NOT_ use Cygwin's textmode.
>>
>> Yes, of course! Who would use Cygwin's textmode :) ?
>
> People who I'm working with. Cygwin's converts CVS working
> copies to Windows line endings if you use textmode. And this
> is what they want.
>
> And as long as textmode is an option in Cygwin's installer
> user will select this option. And after it was removed from
> the installer it will still be there for a couple of years,
> until all existing installations finally disappear.
>
> Because of this situation, I started to work on msysgit.
> I need git without Cygwin.
And btw, no one told me that git is only working in Cygwin if
Cygwin is configured the right way. So I started to advertise
git on Cygwin and people came back to me and told me:
"What crappy tool are you suggesting to use. It's not
even capable of cloning it's own development repository.
I'll not use that tool. Don't steal my time."
Steffen
^ permalink raw reply
* git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-03 8:19 UTC (permalink / raw)
To: git
There are a few svn repositories that use non-standard layout like this:
<path_to_project>/trunk
<path_to_project>/production
<path_to_project>/some_branch
production and some_branch are indeed branched from trunk.
1. How do you init/clone svn repositories like that?
2. Is there a way to add a new svn branch like that (say production
or some_branch) to an existing git-svn repository that has trunk cloned?
Thanks!
__Luke
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Pascal Obry @ 2007-11-03 8:23 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <72D5CB06-9067-47C4-ABDF-4E1F6F4A679D@zib.de>
Steffen Prohaska a écrit :
> "What crappy tool are you suggesting to use. It's not
> even capable of cloning it's own development repository.
> I'll not use that tool. Don't steal my time."
Well it's not because people don't understand how Cygwin is working that
it is to be taken for granted that Cygwin/Git is crap! As I said git svn
is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
repositories without problem. So experience may vary :)
Cygwin is by far the best toolset for Windows developers who don't want
to mess with plain (read very limited) Windows environment.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Andreas Ericsson @ 2007-11-03 8:36 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: git
In-Reply-To: <67837cd60711021303q488e0873lea363b93fc90d591@mail.gmail.com>
Ronald Landheer-Cieslak wrote:
>
> This is also available through git at
> git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
>
This mode of specifying a repository + branch was just thoroughly shot
down in a list discussion, and git certainly doesn't grok it. I'd be a
happier fella if you didn't use it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 9:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When forcing to overwrite an annotated tag, there are good chances one
wants to keep the old annotation, or modify it, not start from scratch.
This is obviously only triggered for annotated tagging (-a or -s).
Signed-off-by: Mike Hommey <mh@glandium.org>
---
The write_annotation function could be made more generic and be used in
various different coming builtins such as git-commit. Also, it could be
used in show_reference() in builtin-tag.c.
builtin-tag.c | 47 ++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 66e5a58..cfd8017 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -247,9 +247,42 @@ static int git_tag_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static void write_annotation(int fd, const unsigned char *sha1)
+{
+ int i;
+ unsigned long size;
+ enum object_type type;
+ char *buf, *sp, *eol;
+ size_t len;
+
+ sp = buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return;
+ if (!size || (type != OBJ_TAG)) {
+ free(buf);
+ return;
+ }
+ /* skip header */
+ while (sp + 1 < buf + size &&
+ !(sp[0] == '\n' && sp[1] == '\n'))
+ sp++;
+ /* strip the signature */
+ for (i = 0, sp += 2; sp < buf + size &&
+ prefixcmp(sp, PGP_SIGNATURE "\n");
+ i++) {
+ eol = memchr(sp, '\n', size - (sp - buf));
+ len = eol ? eol - sp : size - (sp - buf);
+ write_or_die(fd, sp, len + 1);
+ if (!eol)
+ break;
+ sp = eol + 1;
+ }
+ free(buf);
+}
+
static void create_tag(const unsigned char *object, const char *tag,
struct strbuf *buf, int message, int sign,
- unsigned char *result)
+ unsigned char *prev, unsigned char *result)
{
enum object_type type;
char header_buf[1024];
@@ -282,6 +315,10 @@ static void create_tag(const unsigned char *object, const char *tag,
if (fd < 0)
die("could not create file '%s': %s",
path, strerror(errno));
+
+ if (prev)
+ write_annotation(fd, prev);
+
write_or_die(fd, tag_template, strlen(tag_template));
close(fd);
@@ -308,7 +345,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf;
unsigned char object[20], prev[20];
- int annotate = 0, sign = 0, force = 0, lines = 0, message = 0;
+ int annotate = 0, sign = 0, force = 0, lines = 0,
+ message = 0, existed = 0;
char ref[PATH_MAX];
const char *object_ref, *tag;
int i;
@@ -417,9 +455,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
hashclr(prev);
else if (!force)
die("tag '%s' already exists", tag);
+ else
+ existed = 1;
if (annotate)
- create_tag(object, tag, &buf, message, sign, object);
+ create_tag(object, tag, &buf, message, sign,
+ existed ? prev : NULL, object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
--
1.5.3.5
^ permalink raw reply related
* Re: Git-windows and git-svn?
From: Abdelrazak Younes @ 2007-11-03 9:33 UTC (permalink / raw)
To: git
In-Reply-To: <472C2FF8.2000603@obry.net>
Pascal Obry wrote:
> Steffen Prohaska a écrit :
>> "What crappy tool are you suggesting to use. It's not
>> even capable of cloning it's own development repository.
>> I'll not use that tool. Don't steal my time."
>
> Well it's not because people don't understand how Cygwin is working that
> it is to be taken for granted that Cygwin/Git is crap! As I said git svn
> is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
> repositories without problem. So experience may vary :)
OK, thanks for the info.
>
> Cygwin is by far the best toolset for Windows developers who don't want
> to mess with plain (read very limited) Windows environment.
Well some people (including unix people) prefer GUI and context menus
instead of command-line. I must say that I am quite used to TortoiseSVN
and I like it. Never had to do anything at the command-line in order to
use svn. Hum, I am not sure this is the right forum to say this... :-)
Abdel.
^ permalink raw reply
* Re: git rm --cached
From: Remi Vanicat @ 2007-11-03 9:39 UTC (permalink / raw)
To: git
In-Reply-To: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com>
Jing Xue <jingxue@digizenstudio.com> writes:
> 2. The FAQ entry "Why 'git rm' is not inverse of 'git add'" says "a
> natural inverse of 'add' is 'un-add', and that operation is called 'rm
> --cached',..." Now I realize that only applies to adding a new file,
> but not changes on an existing file.
Well, so it seem that to think of "git rm --cached" as inverse to
"git add" is also confusing. The FAQ entry should probably be
rewrite. Or at least clarified.
--
Rémi Vanicat
^ permalink raw reply
* StGIT fails to clean patch series, and to go to a patch
From: Jakub Narebski @ 2007-11-03 9:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I have patch series with empty patch in the middle of the stack.
After trying to stg-clean (and failing) stack looks like below:
1167:[gitweb/web!git]$ stg series -e -s
+ gitweb-Always-set-from_file-to_file
+ gitweb-Add-status_str-diffinfo
+ gitweb-Easier-adding-parameters-to-current-URL
+ gitweb-Use-replay-to-generate-pagination
> gitweb-Use-replay-to-generate-alt-views
0 gitweb-Update-INSTALL-file
- gitweb-No-CGI_Carp-in-test
- gitweb-Test-config-override
- gitweb-Config-reader
- gitweb-Use-config-more
Now stg-rebase works, but stg-goto doesn't work. It returns
the following error.
1164:[gitweb/web!git]$ stg goto gitweb-Use-config-more
Checking for changes in the working directory ... done
Traceback (most recent call last):
File "/usr/bin/stg", line 43, in ?
main()
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/lib/python2.4/site-packages/stgit/commands/goto.py", line 63, in func
push_patches(patches)
File "/usr/lib/python2.4/site-packages/stgit/commands/common.py", line 165, in push_patches
forwarded = crt_series.forward_patches(patches)
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 954, in forward_patches
bottom_tree = git.get_commit(bottom).get_tree()
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 136, in get_commit
commit = Commit(id_hash)
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 77, in __init__
lines = _output_lines(['git-cat-file', 'commit', id_hash])
File "/usr/lib/python2.4/site-packages/stgit/git.py", line 196, in _output_lines
raise GitException, '%s failed (%s)' % (' '.join(cmd),
TypeError: sequence item 2: expected string, NoneType found
1165:[gitweb/web!git]$ stg version
Stacked GIT 0.13
git version 1.5.3.5
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git-windows and git-svn?
From: Steffen Prohaska @ 2007-11-03 9:47 UTC (permalink / raw)
To: Pascal Obry; +Cc: Abdelrazak Younes, Git Mailing List
In-Reply-To: <472C2FF8.2000603@obry.net>
On Nov 3, 2007, at 9:23 AM, Pascal Obry wrote:
> Steffen Prohaska a écrit :
>> "What crappy tool are you suggesting to use. It's not
>> even capable of cloning it's own development repository.
>> I'll not use that tool. Don't steal my time."
>
> Well it's not because people don't understand how Cygwin is working
> that
> it is to be taken for granted that Cygwin/Git is crap! As I said
> git svn
> is only working on Cywgin AFAIK. I'm using Cygwin/Git on many
> repositories without problem. So experience may vary :)
Right. The experience should be good if you use binmode.
But never use textmode. You'll not get an error right away.
At first git seems to work. But later it reports weird errors.
The experience is really bad. Don't do that.
And if you advertise git on Cygwin please tell people to
avoid textmode. It is an important detail.
Steffen
^ permalink raw reply
* Re: [PATCH 5/5] Migrate git-am.sh to use git-rev-parse --parseopt
From: Alex Riesen @ 2007-11-03 9:55 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, torvalds, git
In-Reply-To: <1194043193-29601-6-git-send-email-madcoder@debian.org>
Pierre Habouzit, Fri, Nov 02, 2007 23:39:52 +0100:
> diff --git a/git-am.sh b/git-am.sh
> index 2514d07..e5ed6a7 100755
> --- a/git-am.sh
> +++ b/git-am.sh
...
> - usage ;;
> - *)
> - break ;;
> + -i|--interactive)
> + interactive=t ;;
> + -b|--binary)
> + binary=t ;;
Did you really have to change the indentation?
^ permalink raw reply
* [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Nguyễn Thái Ngọc Duy @ 2007-11-03 10:03 UTC (permalink / raw)
To: git
Without this, work_tree handling code in setup_git_directory
will be activated. If you stay in root work tree (no prefix),
it does not harm. It does if you work from a subdirectory though.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Turns out my patch on NEED_WORK_TREE is fixing a wrong place.
setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index 145eca5..6f8f769 100644
--- a/setup.c
+++ b/setup.c
@@ -240,6 +240,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
+ inside_work_tree = 1;
return retval;
}
if (nongit_ok) {
--
1.5.3.rc4.3.gab089
^ permalink raw reply related
* [PATCH] Don't require working tree for git-rm
From: Mike Hommey @ 2007-11-03 10:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This allows to do git rm --cached -r directory, instead of
git ls-files -z directory | git update-index --remove -z --stdin.
This can be particularly useful for git-filter-branch users.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 4e10581..01dcb6a 100644
--- a/git.c
+++ b/git.c
@@ -345,7 +345,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "rev-list", cmd_rev_list, RUN_SETUP },
{ "rev-parse", cmd_rev_parse, RUN_SETUP },
{ "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
- { "rm", cmd_rm, RUN_SETUP | NEED_WORK_TREE },
+ { "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP | NEED_WORK_TREE },
{ "shortlog", cmd_shortlog, RUN_SETUP | USE_PAGER },
{ "show-branch", cmd_show_branch, RUN_SETUP },
--
1.5.3.5
^ permalink raw reply related
* Re: StGIT fails to clean patch series, and to go to a patch
From: Catalin Marinas @ 2007-11-03 10:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711031045.21506.jnareb@gmail.com>
On 03/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> I have patch series with empty patch in the middle of the stack.
> After trying to stg-clean (and failing) stack looks like below:
Does 'stg delete gitweb-Update-INSTALL-file' work?
> 1164:[gitweb/web!git]$ stg goto gitweb-Use-config-more
> Checking for changes in the working directory ... done
> Traceback (most recent call last):
Does a simple 'stg push' work? I suspect there is something wrong with
the gitweb-Update-INSTALL-file patch but not sure why or how it could
get to this inconsistent state?
It's worth checking the values of 'stg id
gitweb-Update-INSTALL-file//top' and //bottom and whether they are
commit ids or something else.
--
Catalin
^ permalink raw reply
* Re: [StGit RFC] A more structured way of calling git
From: Catalin Marinas @ 2007-11-03 10:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, Git Mailing List, Yann Dirson
In-Reply-To: <20071026192418.GA19774@diana.vm.bytemark.co.uk>
On 26/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> I wanted to build an StGit command that coalesced adjacent patches to
> a single patch. Because the end result tree would still be the same,
> this should be doable without ever involving HEAD, the index, or the
> worktree.
Wouldn't HEAD need to be modified since the commit log changes
slightly, even though the tree is the same. Or am I misunderstanding
this?
> StGit's existing infrastructure for manipulating patches
> didn't lend itself to doing this kind of thing, though: it's not
> modular enough. So I started to design a replacement low-level
> interface to git, and things got slightly out of hand ... and I ended
> up with a much bigger refactoring than I'd planned.
Thanks for this. I'll need a bit of time to read it all and give
feedback. In general, I welcome this refactoring.
I'll go through the whole e-mail in the next days and get back to you.
--
Catalin
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Benoit SIGOURE @ 2007-11-03 10:56 UTC (permalink / raw)
To: Luke Lu; +Cc: git
In-Reply-To: <756D5EE2-FB2C-48DB-8242-14E154E34A9C@vicaya.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
> There are a few svn repositories that use non-standard layout like
> this:
>
> <path_to_project>/trunk
> <path_to_project>/production
> <path_to_project>/some_branch
>
> production and some_branch are indeed branched from trunk.
>
> 1. How do you init/clone svn repositories like that?
I seem to remember that you can pass more than one `-b' option to git-
svn clone, so I'd basically do (untested):
git svn clone <url> -T trunk -b production -b some_branch
> 2. Is there a way to add a new svn branch like that (say production
> or some_branch) to an existing git-svn repository that has trunk
> cloned?
I don't know, but that'd be great indeed.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [ANNOUNCE] cgit v0.7
From: Lars Hjemli @ 2007-11-03 11:08 UTC (permalink / raw)
To: git list
cgit v0.7 (a fast webinterface for git) is now available at
git://hjemli.net/pub/git/cgit
This release includes better search capabilities, better diff,
filtered and sorted branch/tag lists on the summary page, a simple way
to switch between branches and finally a much needed restructuring of
the user interface. There is even a brand new logo, and a number of
bugfixes.
The latest version can be seen in action on http://hjemli.net/git/
(disclaimer: I'm not a web/user interface designer, and should not be
held responsible for any eyeball-related damages).
Big thanks to everyone who submitted patches and feedback!
---
Sortlog since v0.6
Chris Pickel (3):
Makefile: add support for DESTDIR
Make cgit honor CACHE_ROOT as defined in Makefile
Improve the sample cgitrc file
Lars Hjemli (47):
Makefile: add missing references to DESTDIR
cgit v0.6.1
Revert "Makefile: add missing references to DESTDIR"
Revert part of "Makefile: add support for DESTDIR"
cgit v0.6.2
ui-tree: specify parameter position for all htmlf formats
ui-tree: show last line of blob
Add cgit.conf to .gitignore, remove *~
Remove a few compiler warnings
Use trim_end() to remove trailing slashes
Upgrade to GIT 1.5.3.2
cgit v0.6.3
Add support for a renamelimit option in cgitrc
Add prefix parameter to cgit_diff_tree()
Add prefix parameter to cgit_print_diff()
ui-commit.c: link to diff instead of tree from diffstat
css: remove the annoying tr:hover rule for diffstat
gen-version.sh: don't sed the output from git describe
ui-diff: add links to pre- and postversion of blobs
cgit.css: make diff headers more visible
Use git-1.5.3.3
Skip unknown header fields when parsing tags and commits
Add functions and types for ref lists
Use reflist to print branch info
Use reflist to print tag info
Sort tags by age
Add support for config param summary-tags
Move logic for age comparision from cmp_tag_age into cmp_age()
Add support for config param summary-branches
Add descriptions of summary-branches and summary-tags to cgitrc
Make cgit_print_branches()/cgit_print_tags() external
Add support for refs view
Add links to the new refs page from summary page
Cleanup code introduced by the filter-refs topic
cgit_parse_commit(): Add missing call to xstrdup()
Add html_option() function
Teach log search about --grep, --author and --committer
Make print_branch() handle refs not pointing at commits
Teach cgit_object_link() about tag objects
Add config param 'index-info'
Change the cgit layout
Add search parameters to cgit_log_link
Fix search form action/hidden fields
Don't include current path in menu links
Don't include current SHA1 in 'log' menu-item
Use GIT-1.5.3.5
CGIT 0.7
Michael Krelin (2):
fixed typo in cgitrc
correct typo in CSS
Shunichi Fuji (1):
Fix typo in css
^ permalink raw reply
* [PATCH] Make struct commands[] const to save a couple bytes
From: Nguyễn Thái Ngọc Duy @ 2007-11-03 11:13 UTC (permalink / raw)
To: git
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
.data got reduced by 960 bytes. Not much, but anyway ;)
git.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git.c b/git.c
index 4e10581..d0a2042 100644
--- a/git.c
+++ b/git.c
@@ -238,7 +238,7 @@ struct cmd_struct {
int option;
};
-static int run_command(struct cmd_struct *p, int argc, const char **argv)
+static int run_command(const struct cmd_struct *p, int argc, const char **argv)
{
int status;
struct stat st;
@@ -283,7 +283,7 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
- static struct cmd_struct commands[] = {
+ static const struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
@@ -375,7 +375,7 @@ static void handle_internal_command(int argc, const char **argv)
}
for (i = 0; i < ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
+ const struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
exit(run_command(p, argc, argv));
--
1.5.3.rc4.3.gab089
^ permalink raw reply related
* git-svn, tracking branches
From: Pascal Obry @ 2007-11-03 11:16 UTC (permalink / raw)
To: git list
Hi there,
I have "git svn init" a repository to work only on the trunk for the
Subversion repository. I'd like now to work on a branch. I've been able
to do that by editing .git/config, no problem.
My question, is there a better way than hand editing this file ? I've
tried "git remote" but it seems to work only for git repo and there is
no "git svn remote"... Any idea ?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* git reset -- path weirdness
From: Björn Steinbrink @ 2007-11-03 11:17 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, jasampler, gitster
Hi,
I noticed some weirdness with git reset when a path is given. Basically
it seems to cycle the file through 3 states: unstaged, unmerged,
deleted(!) which is IMHO weird at best. A bisection showed that the
behaviour was introduced with the shell -> conversion of git-reset.
Extra annoyance is caused by the fact that "git status" tells you to add
the file when it is in the unmerged state, but that doesn't do anything.
Log of "git reset" switching through the states:
doener@atjola:git (master) $ git status
# On branch master
nothing to commit (working directory clean)
doener@atjola:git (master) $ git reset -- builtin-reset.c
builtin-reset.c: needs merge
doener@atjola:git (master) $ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# unmerged: builtin-reset.c
#
no changes added to commit (use "git add" and/or "git commit -a")
doener@atjola:git (master) $ git reset -- builtin-reset.c
doener@atjola:git (master) $ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: builtin-reset.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# builtin-reset.c
doener@atjola:git (master) $ git reset -- builtin-reset.c
doener@atjola:git (master) $ git status
# On branch master
nothing to commit (working directory clean)
Thanks,
Björn
^ permalink raw reply
* [PATCH 2/3] Use setup_work_tree() in builtin-ls-files.c
From: Mike Hommey @ 2007-11-03 11:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194088993-25692-1-git-send-email-mh@glandium.org>
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-ls-files.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index b70da18..e0b856f 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -525,11 +525,8 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
break;
}
- if (require_work_tree && !is_inside_work_tree()) {
- const char *work_tree = get_git_work_tree();
- if (!work_tree || chdir(work_tree))
- die("This operation must be run in a work tree");
- }
+ if (require_work_tree && !is_inside_work_tree())
+ setup_work_tree();
pathspec = get_pathspec(prefix, argv + i);
--
1.5.3.5
^ permalink raw reply related
* [PATCH 3/3] Don't always require working tree for git-rm
From: Mike Hommey @ 2007-11-03 11:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194088993-25692-2-git-send-email-mh@glandium.org>
This allows to do git rm --cached -r directory, instead of
git ls-files -z directory | git update-index --remove -z --stdin.
This can be particularly useful for git-filter-branch users.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
This replaces the patch from
http://article.gmane.org/gmane.comp.version-control.git/63227
builtin-rm.c | 3 +++
git.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index bca2bd9..a3d25e6 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -155,6 +155,9 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!argc)
usage_with_options(builtin_rm_usage, builtin_rm_options);
+ if (!index_only)
+ setup_work_tree();
+
pathspec = get_pathspec(prefix, argv);
seen = NULL;
for (i = 0; pathspec[i] ; i++)
diff --git a/git.c b/git.c
index eb31c93..4a250f7 100644
--- a/git.c
+++ b/git.c
@@ -340,7 +340,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "rev-list", cmd_rev_list, RUN_SETUP },
{ "rev-parse", cmd_rev_parse, RUN_SETUP },
{ "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
- { "rm", cmd_rm, RUN_SETUP | NEED_WORK_TREE },
+ { "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP | NEED_WORK_TREE },
{ "shortlog", cmd_shortlog, RUN_SETUP | USE_PAGER },
{ "show-branch", cmd_show_branch, RUN_SETUP },
--
1.5.3.5
^ permalink raw reply related
* [PATCH 1/3] Refactor working tree setup
From: Mike Hommey @ 2007-11-03 11:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Create a setup_work_tree() that can be used from any command requiring
a working tree conditionally.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
This kind of implements what Dscho suggested in
http://article.gmane.org/gmane.comp.version-control.git/62487
cache.h | 1 +
git.c | 11 +++--------
setup.c | 9 +++++++++
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/cache.h b/cache.h
index bfffa05..497b9f9 100644
--- a/cache.h
+++ b/cache.h
@@ -222,6 +222,7 @@ extern const char *get_git_work_tree(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
extern const char **get_pathspec(const char *prefix, const char **pathspec);
+extern void setup_work_tree(void);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
extern const char *prefix_path(const char *prefix, int len, const char *path);
diff --git a/git.c b/git.c
index 4e10581..eb31c93 100644
--- a/git.c
+++ b/git.c
@@ -249,14 +249,9 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
prefix = setup_git_directory();
if (p->option & USE_PAGER)
setup_pager();
- if (p->option & NEED_WORK_TREE) {
- const char *work_tree = get_git_work_tree();
- const char *git_dir = get_git_dir();
- if (!is_absolute_path(git_dir))
- set_git_dir(make_absolute_path(git_dir));
- if (!work_tree || chdir(work_tree))
- die("%s must be run in a work tree", p->cmd);
- }
+ if (p->option & NEED_WORK_TREE)
+ setup_work_tree();
+
trace_argv_printf(argv, argc, "trace: built-in: git");
status = p->fn(argc, argv, prefix);
diff --git a/setup.c b/setup.c
index 145eca5..df006d9 100644
--- a/setup.c
+++ b/setup.c
@@ -206,6 +206,15 @@ static const char *set_work_tree(const char *dir)
return NULL;
}
+void setup_work_tree(void) {
+ const char *work_tree = get_git_work_tree();
+ const char *git_dir = get_git_dir();
+ if (!is_absolute_path(git_dir))
+ set_git_dir(make_absolute_path(git_dir));
+ if (!work_tree || chdir(work_tree))
+ die("This operation must be run in a work tree");
+}
+
/*
* We cannot decide in this function whether we are in the work tree or
* not, since the config can only be read _after_ this function was called.
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Johannes Schindelin @ 2007-11-03 11:38 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20071103100323.GA25305@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 918 bytes --]
Hi,
On Sat, 3 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> Without this, work_tree handling code in setup_git_directory
> will be activated. If you stay in root work tree (no prefix),
> it does not harm. It does if you work from a subdirectory though.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Turns out my patch on NEED_WORK_TREE is fixing a wrong place.
>
> setup.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 145eca5..6f8f769 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -240,6 +240,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
> if (chdir(work_tree_env) < 0)
> die ("Could not chdir to %s", work_tree_env);
> strcat(buffer, "/");
> + inside_work_tree = 1;
I really have to wonder why this is needed, as it should be deduced
(correctly!) when you ask is_inside_work_tree().
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-cvsimport: really convert underscores in branch names to dots with -u
From: Gerrit Pape @ 2007-11-03 11:55 UTC (permalink / raw)
To: git, Junio C Hamano
The documentation states for the -u option that underscores in tag and
branch names are converted to dots, but this was actually implemented
for the tag names only.
Kurt Roeckx reported this through
http://bugs.debian.org/446495
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 2954fb8..e4bc2b5 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -818,6 +818,7 @@ while (<CVS>) {
$state = 4;
} elsif ($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
+ tr/_/\./ if ( $opt_u );
s/[\/]/$opt_s/g;
$branch = $_;
$state = 5;
--
1.5.3.5
^ 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