* Re: [RFC (take 2) Git User's Survey 2007
From: Shawn O. Pearce @ 2007-07-31 1:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200707310245.56077.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
> > But I *seriously* object to calling egit a porcelain. egit is a
> > complete reimplementation of git in Java.
>
> O.K. I was not sure where to put egit (if put it at all).
> Implementations? Currently we have core-git in C, egit in Java (what is
> the progress report on this front?), and there was GSoC project of
> Git.NET (but it didn't start I think).
Right, that's an accurate state of affairs. Today egit can make
commits on the current branch. Yay, progress. :)
> Do you want question about egit in the survey?
Might be nice to know how many people are interested in the
Eclipse plugin. But aside from that, I don't think its worth
including much about it. Maybe just have a checkbox under
some heading like:
What features is Git currently missing for your needs?
[ ] Eclipse plugin
[ ] wizhbang foo thing
[ ] Other: ________________________
?
--
Shawn.
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Junio C Hamano @ 2007-07-31 0:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301744050.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Jul 2007, Junio C Hamano wrote:
>>
>> I guess so, but can higher stage entries have cached stat
>> information that are valid and match the working tree?
>
> Probably unlikely, but I could imagine that it's the case for things that
> failed to merge entirely (ie binaries), where you end up just saying "pick
> the old/base binary", and it ends up matching in stage1.
Probably. In any case, what I'll commit will have the stage#0
check, just to be safe anyway.
Thanks for the sanity. Really appreciate it.
^ permalink raw reply
* Re: [RFC (take 2) Git User's Survey 2007
From: Jakub Narebski @ 2007-07-31 0:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <20070731003251.GW20052@spearce.org>
Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > How you use GIT
> >
> > 8. Which porcelains do you use?
> > (zero or more: multiple choice)
> > - core-git, cogito, StGIT, pg, guilt, egit (Eclipse), other
> > 9. Which git GUI do you use
> > (zero or more: multiple choice)
> > - gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
> > (h)gct, qct, KGit, other
>
> I'll give you git-gui as a GUI here instead of a porcelain.
>
> But I *seriously* object to calling egit a porcelain. egit is a
> complete reimplementation of git in Java. Calling it a porcelain
> is wrong. Robin, David and myself have put a considerable amount
> of effort into keeping egit 100% pure Java, so it is Write Once,
> Test Everywhere.
>
> The _only_ code that egit has borrowed from core Git has been the
> packfile delta decompressor. Everything else is a reimplementation.
> Just not 100% blackbox, as the egit developers have looked at the
> core Git source before. Heck, we have even been known to contribute
> a patch here or there to core Git. :)
>
> All of the other porcelains that you listed reuse the core Git
> plumbing and are thus true porcelain. But egit doesn't.
O.K. I was not sure where to put egit (if put it at all).
Implementations? Currently we have core-git in C, egit in Java (what is
the progress report on this front?), and there was GSoC project of
Git.NET (but it didn't start I think).
Do you want question about egit in the survey?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-31 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <7vsl75igtt.fsf@assigned-by-dhcp.cox.net>
On Mon, 30 Jul 2007, Junio C Hamano wrote:
>
> I guess so, but can higher stage entries have cached stat
> information that are valid and match the working tree?
Probably unlikely, but I could imagine that it's the case for things that
failed to merge entirely (ie binaries), where you end up just saying "pick
the old/base binary", and it ends up matching in stage1.
Linus
^ permalink raw reply
* Re: [RFC (take 2) Git User's Survey 2007
From: Shawn O. Pearce @ 2007-07-31 0:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200707302256.38251.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> How you use GIT
>
> 8. Which porcelains do you use?
> (zero or more: multiple choice)
> - core-git, cogito, StGIT, pg, guilt, egit (Eclipse), other
> 9. Which git GUI do you use
> (zero or more: multiple choice)
> - gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
> (h)gct, qct, KGit, other
I'll give you git-gui as a GUI here instead of a porcelain.
But I *seriously* object to calling egit a porcelain. egit is a
complete reimplementation of git in Java. Calling it a porcelain
is wrong. Robin, David and myself have put a considerable amount
of effort into keeping egit 100% pure Java, so it is Write Once,
Test Everywhere.
The _only_ code that egit has borrowed from core Git has been the
packfile delta decompressor. Everything else is a reimplementation.
Just not 100% blackbox, as the egit developers have looked at the
core Git source before. Heck, we have even been known to contribute
a patch here or there to core Git. :)
All of the other porcelains that you listed reuse the core Git
plumbing and are thus true porcelain. But egit doesn't.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-07-31 0:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11858118802945-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> git gui is especially useful because it allows to select diff hunks.
> Now it is at least mentioned in the user-manual.
> +Another approach for creating commits is git gui:
> +
> +-------------------------------------------------
> +$ git gui citool
> +-------------------------------------------------
Actually `git citool` is an alias for `git gui citool`. Because the
former is much faster to type when you want to make a quick commit.
:-)
> +
> +starts the commit tool (Note, "`git gui`" starts the full gui, which
> +provides more options).
But this note is also really useful. So maybe talking about the
longer form in the user manual is a good way to introduce git-gui.
> +Beyond the basic operation of staging and unstaging complete files,
> +git gui can also selectively stage diff hunks. You can do so by
> +selecting a modified or staged file and right-click on the diff view
> +in the lower part of the gui. A pop-up will appear that lets you
> +select a specific hunk and stage or unstage it for the next commit.
> +This is particular useful for slicing large, ugly commits into smaller
> +pieces, for example when cherry-picking (see
> +<<reordering-patch-series>>).
Yes. Now if only someone would teach it how to let you highlight a
section and stage/unstage just the selection. Never mind splitting
a hunk. Selection based stage/unstage would really be cool...
especially when combined with git-stash. Where you could first
stash everything, reset back to the last committed state, then
selectively unstash changes into the working directory, test them,
stage everything for commit, then unstash more, etc...
Since git-stash is modeled as a commit, it could also work for
cherry-picking. Which is very useful when cleaning up a series.
Hmm. Wishlist for git-gui!
> @@ -2480,7 +2498,8 @@ $ gitk origin..mywork &
> And browse through the list of patches in the mywork branch using gitk,
> applying them (possibly in a different order) to mywork-new using
> cherry-pick, and possibly modifying them as you go using commit
> ---amend.
> +--amend. git gui may be especially useful to amend commits as it
> +lets you selectively stage and unstage single diff hunks.
Yes. Except git-gui (currently) destroys the author information
when it does an amend. Bad git-gui! Bad! No prize for you! :-)
--
Shawn.
^ permalink raw reply
* Re: (Resend)[PATCH] git-svn: Translate invalid characters in refname
From: Junio C Hamano @ 2007-07-31 0:20 UTC (permalink / raw)
To: Robert Ewald; +Cc: git
In-Reply-To: <f8k9q5$927$1@sea.gmane.org>
This patch is totally whitespace mangled, but I'll apply by hand
for now.
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Junio C Hamano @ 2007-07-30 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301624050.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 30 Jul 2007, Junio C Hamano wrote:
>>
>> We would need to do something like this patch, perhaps? This
>> function has three callers, two in builtin-add and another in
>> builtin-mv.
>
> I think you need to check that ce is in stage 0 too.
I guess so, but can higher stage entries have cached stat
information that are valid and match the working tree?
---
read-cache.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
diff --git a/read-cache.c b/read-cache.c
index a363f31..9c00ccb 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -380,7 +380,7 @@ static int index_name_pos_also_unmerged(struct index_state *istate,
int add_file_to_index(struct index_state *istate, const char *path, int verbose)
{
- int size, namelen;
+ int size, namelen, pos;
struct stat st;
struct cache_entry *ce;
@@ -414,6 +414,15 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)
ce->ce_mode = ce_mode_from_stat(ent, st.st_mode);
}
+ pos = index_name_pos(istate, ce->name, namelen);
+ if (0 <= pos &&
+ !ce_stage(istate->cache[pos]) &&
+ !ie_modified(istate, istate->cache[pos], &st, 1)) {
+ /* Nothing changed, really */
+ free(ce);
+ return 0;
+ }
+
if (index_path(ce->sha1, path, &st, 1))
die("unable to index file %s", path);
if (add_index_entry(istate, ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE))
^ permalink raw reply related
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-30 23:30 UTC (permalink / raw)
To: Craig Boston; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070730222028.GE64467@nowhere>
On Mon, 30 Jul 2007, Craig Boston wrote:
>
> # On branch cvs_RELENG_4
> nothing to commit (working directory clean)
> git: 67.65 seconds
So I _seriously_ hope that about 65 of those 67 seconds was the "cvs
update -d" or something like that.
Anything that takes a minute in git is way way *way* too slow. Any
half-way normal git operations should take less than a second.
Linus
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-30 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <7vy7gximkc.fsf@assigned-by-dhcp.cox.net>
On Mon, 30 Jul 2007, Junio C Hamano wrote:
>
> We would need to do something like this patch, perhaps? This
> function has three callers, two in builtin-add and another in
> builtin-mv.
I think you need to check that ce is in stage 0 too.
Linus
^ permalink raw reply
* Re: [PATCH] git.el: Support for incremental status updates.
From: Karl Hasselström @ 2007-07-30 23:22 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87sl7ekt40.fsf@wine.dyndns.org>
On 2007-07-24 12:12:47 +0200, Alexandre Julliard wrote:
> + (if node (ewoc-set-data node info) (ewoc-enter-last status info))))
My emacs doesn't like this. When i do "a" or "U" (and quite possibly
others that I haven't tried yet) I get
git-insert-fileinfo: Symbol's function definition is void: ewoc-set-data
The command appears to have been aborted, but if I press "g" to
refresh the display, I see that it has in fact been carried out. So
there is a workaround, at least.
This is GNU Emacs 21.4.1 on Ubuntu 7.04.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-30 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <7vps29k3gm.fsf@assigned-by-dhcp.cox.net>
On Mon, 30 Jul 2007, Junio C Hamano wrote:
>
> By the way, the above "something more complex" may be a simple
> "git add -u".
No, that doesn't add new files, only already tracked ones.
Linus
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: David Kastrup @ 2007-07-30 22:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <200707302337.07957.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup wrote:
>> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>>
>> > Fine with me. Thanks for you work Jakub.
>> >
>> > Just a general comment, let's try to avoid as much as possible
>> > multiple questions in a single question. It tends to confuse people
>> > when they are answering to the survey.
>>
>> I find that the survey lacking in community questions, like
>>
>> Do you frequently read the mailing list?
>> Frequently post?
>> Other sources of information?
>> How helpful are the answers you get there?
>> How pleasant is the atmosphere?
>
> I think the most important ones are there:
> ----
> Getting help, staying in touch
>
> 1. Have you tried to get GIT help from other people?
> - yes/no
[...]
Well, I have a winning streak of stupid oversights right now. You are
quite right.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Introduce entry point for launching add--interactive.
From: Kristian Høgsberg @ 2007-07-30 22:21 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
This refactors builtin-add.c a little to provide a unique entry point
for launching git add --interactive, which will be used by
builtin-commit too. If we later want to make add --interactive a
builtin or change how it is launched, we just start from this function.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
Oh, oops, just one more change outside builtin-commit.c. This is mostly
stylistic, but it seems reasonable to reasonable to have a well-defined
entry point for launcing git add --interactive.
builtin-add.c | 14 +++++++++-----
commit.h | 2 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 7345479..7044d43 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -135,6 +135,13 @@ static int git_add_config(const char *var, const char *value)
return git_default_config(var, value);
}
+int interactive_add(void)
+{
+ const char *argv[2] = { "add--interactive", NULL };
+
+ return run_command_v_opt(argv, RUN_GIT_CMD);
+}
+
static struct lock_file lock_file;
static const char ignore_warning[] =
@@ -154,12 +161,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
add_interactive++;
}
if (add_interactive) {
- const char *args[] = { "add--interactive", NULL };
-
- if (add_interactive != 1 || argc != 2)
+ if (argc != 2)
die("add --interactive does not take any parameters");
- execv_git_cmd(args);
- exit(1);
+ exit(interactive_add());
}
git_config(git_add_config);
diff --git a/commit.h b/commit.h
index 9f640ba..64e1d4b 100644
--- a/commit.h
+++ b/commit.h
@@ -129,4 +129,6 @@ create_commit(const unsigned char *tree_sha1,
const char *author_info, const char *committer_info,
const char *message, int length);
+extern int interactive_add(void);
+
#endif /* COMMIT_H */
--
1.5.2.GIT
^ permalink raw reply related
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-30 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301240330.4161@woody.linux-foundation.org>
>
> [ snip lots of helpful comments from various people ]
>
I just wanted to say thanks to Linus and Junio and everyone who
commented, I think I have a much more workable solution now. With my
brute-force remove and re-add everything script the times for import
looked like this:
Importing /compile/co/RELENG_4 (no changes):
svk import: 166.86 seconds
git: 455.82 seconds
Importing /compile/co/RELENG_6:
svk import: 203.69 seconds
git: 796.48 seconds
Importing /compile/co/HEAD:
svk import: 243.90 seconds
git: 837.13 seconds
Ok, so I remembered wrong, git was only 4x slower. Still, I knew it
could do better than that...
After transplanting the .git directory from 3 cloned repositories
checked out to the appropriate branch into the CVS checkout directories,
priming them with a 'git status', and using the git ls-file | git
update-index trick followed by commit -a, here are the revised times:
# On branch cvs_RELENG_4
nothing to commit (working directory clean)
git: 67.65 seconds
Created commit 106bc0b: Import 20070730 snapshot
7 files changed, 259 insertions(+), 75 deletions(-)
Git repository at /compile/co/RELENG_6/src updated
git: 62.02 seconds
Created commit 776031b: Import 20070730 snapshot
86 files changed, 10929 insertions(+), 587 deletions(-)
[snip lots of lines for added files]
Git repository at /compile/co/HEAD/src updated
git: 61.77 seconds
_MUCH_ better. I knew it had to be capable of faster :-)
Again, thanks for all the help. I look forward to seeing what else git
can do!
Craig
^ permalink raw reply
* Re: merge time
From: Robin Rosenberg @ 2007-07-30 22:11 UTC (permalink / raw)
To: Matthew L Foster; +Cc: david, Linus Torvalds, git
In-Reply-To: <104942.93033.qm@web51008.mail.re2.yahoo.com>
måndag 30 juli 2007 skrev Matthew L Foster:
>
> --- david@lang.hm wrote:
>
> > On Mon, 30 Jul 2007, Matthew L Foster wrote:
> > > Local commit order is stored locally right?
> >
> > not normally. you could enable reflogs and then mine through the reflogs
> > to find the info, but it's not stored in any easy to access fashion.
>
> Local merge order can be extracted from git?
Well.. depending on what your definition of merge. Yes, probably.
I dislike the term "merge" here, since no merges has to be involved, unless you
include any pulled commit into the terms. Normally a merge is a commit with
two or more parents. Fast forward merges are indistinguishable from normal
commits.
That aside, you *can* (usually) figure the time when a commit entered the repository by examining the
reflog if the set of branches are reasonably stable The reflog gives the local time when a head
was modified (old and new commit) so from there you can usually go backwards. *But* that road is
full of pot holes. The reflog cannot per se tell when a commit entered the local repo, it can
tell when it came into view as seen from a particular head. Looking from different heads may
(will) give you different times. If the head that was used to pull the commit into the repo is
deleted you will not be able to tell when the commit entered the repo, nor will you be able to
tell whether you can tell that or not, since the reflog for that head is gone.
The reflog doesn't list all commits, just changes to the head and it isn't necessarily linear either, ie.
it may change backward in "time" forward or even to a completely separate set of commits.
The reflog is text-only: .git/logs/<ref-name>, e.g. .git/logs/refs/heads/master so you can see for
yourself.
-- robin
^ permalink raw reply
* Re: merge time
From: Jakub Narebski @ 2007-07-30 21:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707301007020.11330@asgard.lang.hm>
david@lang.hm wrote:
> if someone really wanted to do this, the right answer may be to take the
> concept of gitk and webify it (think SVG for the graphics and AJAX
> interfaces to retreive the info as needed). I think this would be a very
> useful tool, but it would be a lot of work to implement.
>
> but without the graph showing the commits and how they are related to each
> other, you really are crippled in your ability to figure out how things
> are related to each other. Date order just doesn't cut it.
By the way, gitweb at repo.or.cz has graphical log (a la gitk) using
git-browser by Arteem Khodush, which uses JavaScript library for graphics
(creating lines box by box) and a bit of AJAX-ism.
I was thinking about using "template" PNG with transparency and colored
boxes to have lighter than git-browser graphical history in gitweb, but...
By the way, you can try to add --topo-order support to gitweb, although I'm
not sure if it would do what you want.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: David Kastrup @ 2007-07-30 21:54 UTC (permalink / raw)
To: Craig Boston; +Cc: git
In-Reply-To: <20070730180710.GA64467@nowhere>
Craig Boston <craig@olyun.gank.org> writes:
> So far the main snag I've found is that AFAIK there's no equivalent to
> "svk import" to load a big tree (~37000 files) into a branch and commit
> the changes. Here's the procedure I've come up with:
>
> cd /path/to/git/repo
> git checkout vendor_branch_X
> git rm -r .
> cp -R /path/to/cvs/checkout_X/* ./
> git add .
> git commit -m"Import yyyymmdd snapshot"
I have not tried it, but shouldn't something like the following work?
cd /path/to/cvs/checkout_X
git --git-dir=/path/to/git/repo/.git reset vendor_branch_X
git --git-dir=/path/to/git/repo/.git add .
git --git-dir=/path/to/git/repo/.git commit -a -m "Import yyyymmdd snapshot"
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Junio C Hamano @ 2007-07-30 21:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301240330.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Junio? I _thought_ we already took the index into account with "git add",
> but we obviously don't.
I think 366bfcb6 "broke" it by moving read_cache() call down,
because it wanted the directory walking code to grab paths that
are already in the index. The change serves its purpose, but
introduces this regression now the responsibility of avoiding
unnecessary reindexing by matching the cached stat is shifted
nowhere.
We would need to do something like this patch, perhaps? This
function has three callers, two in builtin-add and another in
builtin-mv.
---
read-cache.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index a363f31..c346d88 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -380,7 +380,7 @@ static int index_name_pos_also_unmerged(struct index_state *istate,
int add_file_to_index(struct index_state *istate, const char *path, int verbose)
{
- int size, namelen;
+ int size, namelen, pos;
struct stat st;
struct cache_entry *ce;
@@ -414,6 +414,13 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)
ce->ce_mode = ce_mode_from_stat(ent, st.st_mode);
}
+ pos = index_name_pos(istate, ce->name, namelen);
+ if (0 <= pos && !ie_modified(istate, istate->cache[pos], &st, 1)) {
+ /* Nothing changed, really */
+ free(ce);
+ return 0;
+ }
+
if (index_path(ce->sha1, path, &st, 1))
die("unable to index file %s", path);
if (add_index_entry(istate, ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE))
^ permalink raw reply related
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-30 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vabtdk2ch.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 30, 2007 at 02:29:02PM -0700, Junio C Hamano wrote:
> Craig Boston <craig@olyun.gank.org> writes:
> > 2) Have one repository clone that gets re-used for each import, with the
> > "checked out" branch getting changed before the import. As far as I can
> > tell this means suffering the "git checkout" overhead for 30,000 files,
> > which is conceptually inefficient but in real time only a minute or so.
>
> That should only be "conceptually" in fact, as switching between
> branches should not touch paths that are the same between
> branches.
I suspected as much, though in practice almost every file is different
between the branches that I'm tracking. RELENG_4 and RELENG_6 for
instance have years of development between them, with almost every major
subsystem and API reorganized in some way.
I might have to do a quick compare once I get things imported and see
exactly what the numbers are.
Craig
^ permalink raw reply
* Recent strbuf/builtin-commit-tree/wt-status patch series
From: Kristian Høgsberg @ 2007-07-30 21:48 UTC (permalink / raw)
To: git
Hi,
I forgot -n to format-patch, sorry. The ordering I have here is
[PATCH] Add test case for basic commit functionality.
[PATCH] Enable wt-status output to a given FILE pointer.
[PATCH] Add strbuf_printf() to do formatted printing to a
strbuf.
[PATCH] Make builtin-commit-tree use a strbuf instead of
hand-rolled realloc buffer.
[PATCH] Split out the actual commit creation from the option
parsing etc.
and finally
[PATCH] Split out the actual commit creation from the option
parsing etc.
It fell out of the series when I reordered some patches, so I sent it
separately.
This series is some infrastructure changes and the test case I've been
using for my work on builtin-commit. They are all immediately
committable, and constitute most of the changes to git required by
builtin-commit.
cheers,
Kristian
^ permalink raw reply
* [PATCH] Enable wt-status to run against non-standard index file.
From: Kristian Høgsberg @ 2007-07-30 21:35 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
We still default to get_index_file(), but this can be overridden
by setting wt_status.index_file after calling wt_status_prepare().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
wt-status.c | 3 ++-
wt-status.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 65a7259..0cf9b81 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -53,6 +53,7 @@ void wt_status_prepare(struct wt_status *s)
s->branch = head ? xstrdup(head) : NULL;
s->reference = "HEAD";
s->fp = stdout;
+ s->index_file = get_index_file();
}
static void wt_status_print_cached_header(struct wt_status *s)
@@ -198,7 +199,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
static void wt_read_cache(struct wt_status *s)
{
discard_cache();
- read_cache();
+ read_cache_from(s->index_file);
}
static void wt_status_print_initial(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 4f3a615..7744932 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -21,6 +21,7 @@ struct wt_status {
int commitable;
int workdir_dirty;
int workdir_untracked;
+ const char *index_file;
FILE *fp;
};
--
1.5.2.GIT
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 21:37 UTC (permalink / raw)
To: David Kastrup; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <85myxdu206.fsf@lola.goethe.zz>
David Kastrup wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > Fine with me. Thanks for you work Jakub.
> >
> > Just a general comment, let's try to avoid as much as possible
> > multiple questions in a single question. It tends to confuse people
> > when they are answering to the survey.
>
> I find that the survey lacking in community questions, like
>
> Do you frequently read the mailing list?
> Frequently post?
> Other sources of information?
> How helpful are the answers you get there?
> How pleasant is the atmosphere?
I think the most important ones are there:
----
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
- yes/no
2. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
3. Do you subscribe to the mailing list?
- yes/no
4. Do you read the mailing list? What method do you use?
- subscribed/news interface/RSS interface/archives/
/post + reply-to request/digests/I don't read it
5. If yes, do you find it useful?
- yes/no (optional)
6. Do you find traffic levels on GIT mailing list OK.
- yes/no? (optional)
7. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
8. If yes, do you find IRC channel useful?
- yes/no (optional)
----
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 21:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <fcaeb9bf0707301425y58b423f6x6141949845483e01@mail.gmail.com>
On Mon, 30 July 2007, Nguyen Thai Ngoc Duy wrote:
> On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> It's been more than a year since last Git User's Survey. It would be
>> interesting to find what changed since then. Therefore the idea to
>> have another survey.
>
> I am probably going a little far here. I think we should include
> briefly in the survey announcement what git has achieved since the
> last survey. We want to know what changed from users. Maybe users also
> want to know what changed from git since then. Also it would be good
> advertisement if it gets posted on online magazines and popular sites.
Well, there are in the survey questions about changes in GIT:
----
Changes in GIT (since year ago, or since you started using it)
0. Did you participate in previous Git User's Survey?
- yes/no
1. What improvements you wanted got implemented?
2. What improvements you wanted didn't get implemented?
3. How do you compare current version iwth version from year ago?
- current version is: better/worse/no changes
4. Which of the new features do you use?
(zero or more: multiple choice)
- git-gui, bundle, eol conversion, gitattributes,
submodules, worktree, release notes, user's manual,
reflog, stash, shallow clone, detached HEAD, fast-import,
mergetool, other (not mentioned here)
5. If you selected "other", what are those features?
----
Regarding announcement of what git has achieved since last survey:
I'm not sure what is the full list. RelNotes are fairly recent,
unfortunately...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 5/5] Split out the actual commit creation from the option parsing etc.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
In-Reply-To: <11858309322915-git-send-email-krh@redhat.com>
From: Kristian Høgsberg <krh@redhat.com>
The functionality is available inside git through the function
create_commit().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit-tree.c | 96 ++++++++++++++++++++++++++++++------------------
commit.h | 7 ++++
2 files changed, 67 insertions(+), 36 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 72884eb..e20f0b4 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -52,15 +52,59 @@ static const char commit_utf8_warn[] =
"You may want to amend it after fixing the message, or set the config\n"
"variable i18n.commitencoding to the encoding your project uses.\n";
+const unsigned char *
+create_commit(const unsigned char *tree_sha1,
+ unsigned char parent_sha1[][20], int parents,
+ const char *author_info, const char *committer_info,
+ const char *message, int length)
+{
+ static unsigned char commit_sha1[20];
+ int encoding_is_utf8, i;
+ struct strbuf sb;
+
+ /* Not having i18n.commitencoding is the same as having utf-8 */
+ encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
+
+ strbuf_init(&sb);
+ strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
+
+ /*
+ * NOTE! This ordering means that the same exact tree merged with a
+ * different order of parents will be a _different_ changeset even
+ * if everything else stays the same.
+ */
+ for (i = 0; i < parents; i++)
+ strbuf_printf(&sb, "parent %s\n", sha1_to_hex(parent_sha1[i]));
+
+ /* Person/date information */
+ strbuf_printf(&sb, "author %s\n", author_info);
+ strbuf_printf(&sb, "committer %s\n", committer_info);
+ if (!encoding_is_utf8)
+ strbuf_printf(&sb, "encoding %s\n", git_commit_encoding);
+ strbuf_printf(&sb, "\n");
+
+ /* And add the comment */
+ strbuf_add(&sb, message, length);
+
+ /* And check the encoding */
+ strbuf_add_char(&sb, '\0');
+ if (encoding_is_utf8 && !is_utf8(sb.buf))
+ fprintf(stderr, commit_utf8_warn);
+
+ if (!write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1))
+ return commit_sha1;
+
+ return NULL;
+}
+
int cmd_commit_tree(int argc, const char **argv, const char *prefix)
{
int i;
int parents = 0;
unsigned char tree_sha1[20];
- unsigned char commit_sha1[20];
- char comment[1000];
- struct strbuf sb;
- int encoding_is_utf8;
+ char *buffer;
+ unsigned long len;
+ const unsigned char *commit_sha1;
git_config(git_default_config);
@@ -85,40 +129,20 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
parents++;
}
- /* Not having i18n.commitencoding is the same as having utf-8 */
- encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
+ buffer = NULL;
+ if (read_fd(0, &buffer, &len))
+ die("Could not read commit message from standard input");
- strbuf_init(&sb);
- strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
+ commit_sha1 = create_commit(tree_sha1,
+ parent_sha1, parents,
+ xstrdup(git_author_info(1)),
+ xstrdup(git_committer_info(1)),
+ buffer, len);
- /*
- * NOTE! This ordering means that the same exact tree merged with a
- * different order of parents will be a _different_ changeset even
- * if everything else stays the same.
- */
- for (i = 0; i < parents; i++)
- strbuf_printf(&sb, "parent %s\n", sha1_to_hex(parent_sha1[i]));
-
- /* Person/date information */
- strbuf_printf(&sb, "author %s\n", git_author_info(1));
- strbuf_printf(&sb, "committer %s\n", git_committer_info(1));
- if (!encoding_is_utf8)
- strbuf_printf(&sb, "encoding %s\n", git_commit_encoding);
- strbuf_printf(&sb, "\n");
-
- /* And add the comment */
- while (fgets(comment, sizeof(comment), stdin) != NULL)
- strbuf_printf(&sb, "%s", comment);
+ if (!commit_sha1)
+ return 1;
- /* And check the encoding */
- strbuf_add_char(&sb, '\0');
- if (encoding_is_utf8 && !is_utf8(sb.buf))
- fprintf(stderr, commit_utf8_warn);
+ printf("%s\n", sha1_to_hex(commit_sha1));
- if (!write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {
- printf("%s\n", sha1_to_hex(commit_sha1));
- return 0;
- }
- else
- return 1;
+ return 0;
}
diff --git a/commit.h b/commit.h
index 467872e..9f640ba 100644
--- a/commit.h
+++ b/commit.h
@@ -122,4 +122,11 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
int in_merge_bases(struct commit *, struct commit **, int);
+
+extern const unsigned char *
+create_commit(const unsigned char *tree_sha1,
+ unsigned char parent_sha1[][20], int parents,
+ const char *author_info, const char *committer_info,
+ const char *message, int length);
+
#endif /* COMMIT_H */
--
1.5.2.GIT
^ 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