* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Nicolas Pitre @ 2006-12-09 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7vd56tei20.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 8 Dec 2006, Junio C Hamano wrote:
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * So how about this?
Much better. Comments below.
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 517a86b..8fe42cb 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -14,25 +14,47 @@ SYNOPSIS
>
> DESCRIPTION
> -----------
> -Updates the index file for given paths, or all modified files if
> -'-a' is specified, and makes a commit object. The command specified
> -by either the VISUAL or EDITOR environment variables are used to edit
> -the commit log message.
> +Use 'git commit' when you want to record your changes into the repository
> +along with a log message describing what the commit is about. All changes
> +to be committed must be explicitly identified using one of the following
> +methods:
>
> -Several environment variable are used during commits. They are
> -documented in gitlink:git-commit-tree[1].
> +1. by using gitlink:git-add[1] to incrementally "add" changes to the
> + next commit before using the 'commit' command (Note: even modified
> + files must be "added");
>
> +2. by using gitlink:git-rm[1] to identify content removal for the next
> + commit, again before using the 'commit' command;
> +
> +3. by directly listing files containing changes to be committed as arguments
> + to the 'commit' command, in which cases only those files alone will be
> + considered for the commit;
> +
> +4. by using the -a switch with the 'commit' command to automatically "add"
> + changes from all known files i.e. files that have already been committed
> + before, and perform the actual commit.
> +
> +Note that the contents of the paths that resolved cleanly by a
> +conflicted merge are automatically staged for the next commit;
> +you still need to explicitly identify what you want in the
> +resulting commit using one of the above methods before
> +recording the merge commit.
Like I said in another mail, I really think this formal paragraph
belongs elsewhere. But if you insist for keeping it here, at least it
should be moved after mention of git-reset below. But IMHO the merge
example included further down should be sufficient information wrt
committing a merge.
> +
> +The gitlink:git-status[1] command can be used to obtain a
> +summary of what is included by any of the above for the next
> +commit by giving the same set of parameters you would give to
> +this command.
> +
> +If you make a commit and then found a mistake immediately after
> +that, you can recover from it with gitlink:git-reset[1].
>
> -This command can run `commit-msg`, `pre-commit`, and
> -`post-commit` hooks. See link:hooks.html[hooks] for more
> -information.
>
> OPTIONS
> -------
> -a|--all::
> - Update all paths in the index file. This flag notices
> - files that have been modified and deleted, but new files
> - you have not told git about are not affected.
> + Tell the command to automatically stage files that have
> + been modified and deleted, but new files you have not
> + told git about are not affected.
>
> -c or -C <commit>::
> Take existing commit object, and reuse the log message
> @@ -55,16 +77,13 @@ OPTIONS
> -s|--signoff::
> Add Signed-off-by line at the end of the commit message.
>
> --v|--verify::
> - Look for suspicious lines the commit introduces, and
> - abort committing if there is one. The definition of
> - 'suspicious lines' is currently the lines that has
> - trailing whitespaces, and the lines whose indentation
> - has a SP character immediately followed by a TAB
> - character. This is the default.
> -
> --n|--no-verify::
> - The opposite of `--verify`.
> +--no-verify::
> + By default, the command looks for suspicious lines the
> + commit introduces, and aborts committing if there is one.
> + The definition of 'suspicious lines' is currently the
> + lines that has trailing whitespaces, and the lines whose
> + indentation has a SP character immediately followed by a
> + TAB character. This option turns off the check.
>
> -e|--edit::
> The message taken from file with `-F`, command line with
> @@ -95,16 +114,16 @@ but can be used to amend a merge commit.
> --
>
> -i|--include::
> - Instead of committing only the files specified on the
> - command line, update them in the index file and then
> - commit the whole index. This is the traditional
> - behavior.
> + Before making a commit out of staged contents so far,
> + stage the contents of paths given on the command line
> + as well. This is usually not what you want unless you
> + are concluding a conflicted merge.
>
> -o|--only::
> - Commit only the files specified on the command line.
> - This format cannot be used during a merge, nor when the
> - index and the latest commit does not match on the
> - specified paths to avoid confusion.
> + Commit only the files specified on the command line;
> + this is the default when pathnames are given on the
> + command line, so you usually do not have to give this
> + option. This format cannot be used during a merge.
Is there some value in keeping this option documented? What about
removing it (the documentation not the option)?
> \--::
> Do not interpret any more arguments as options.
> @@ -114,50 +133,112 @@ but can be used to amend a merge commit.
> different between `--include` and `--only`. Without
> either, it defaults `--only` semantics.
>
> -If you make a commit and then found a mistake immediately after
> -that, you can recover from it with gitlink:git-reset[1].
> -
> -
> -Discussion
> -----------
> -
> -`git commit` without _any_ parameter commits the tree structure
> -recorded by the current index file. This is a whole-tree commit
> -even the command is invoked from a subdirectory.
> -
> -`git commit --include paths...` is equivalent to
> -
> - git update-index --remove paths...
> - git commit
> -
> -That is, update the specified paths to the index and then commit
> -the whole tree.
> -
> -`git commit paths...` largely bypasses the index file and
> -commits only the changes made to the specified paths. It has
> -however several safety valves to prevent confusion.
> -
> -. It refuses to run during a merge (i.e. when
> - `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
> - that the traditional semantics now needs -i flag.
> -
> -. It refuses to run if named `paths...` are different in HEAD
> - and the index (ditto about reminding). Added paths are OK.
> - This is because an earlier `git diff` (not `git diff HEAD`)
> - would have shown the differences since the last `git
> - update-index paths...` to the user, and an inexperienced user
> - may mistakenly think that the changes between the index and
> - the HEAD (i.e. earlier changes made before the last `git
> - update-index paths...` was done) are not being committed.
> -
> -. It reads HEAD commit into a temporary index file, updates the
> - specified `paths...` and makes a commit. At the same time,
> - the real index file is also updated with the same `paths...`.
> -
> -`git commit --all` updates the index file with _all_ changes to
> -the working tree, and makes a whole-tree commit, regardless of
> -which subdirectory the command is invoked in.
>
> +EXAMPLES
> +--------
> +When recording your own work, the contents of modified files in
> +your working tree are temporarily stored to a staging area
> +called the "index" with gitlink:git-add[1]. Removal
I like the way the index is introduced at this point.
> +of a file is staged with gitlink:git-rm[1]. After building the
> +state to be committed incrementally with these commands, `git
> +commit` (without any pathname parameter) is used to record what
> +has been staged so far. This is the most basic form of the
> +command. An example:
> +
> +------------
> +$ edit hello.c
> +$ git rm goodbye.c
> +$ git add hello.c
> +$ git commit
> +------------
> +
> +////////////
> +We should fix 'git rm' to remove goodbye.c from both index and
> +working tree for the above example.
> +////////////
> +
> +Instead of staging files after each individual change, you can
> +tell `git commit` to notice the changes to the tracked files in
> +your working tree and do corresponding `git add` and `git rm`
> +for you. That is, this example does the same as the earlier
> +example if there is no other change in your working tree:
> +
> +------------
> +$ edit hello.c
> +$ rm goodbye.c
> +$ git commit -a
> +------------
> +
> +The command `git commit -a` first looks at your working tree,
> +notices that you have modified hello.c and removed goodbye.c,
> +and performs necessary `git add` and `git rm` for you.
> +
> +After staging changes to many files, you can alter the order the
> +changes are recorded in, by giving pathnames to `git commit`.
> +When pathnames are given, the command makes a commit that
> +only records the changes made to the named paths:
> +
> +------------
> +$ edit hello.c hello.h
> +$ git add hello.c hello.h
> +$ edit Makefile
> +$ git commit Makefile
> +------------
> +
> +This makes a commit that records the modification to `Makefile`.
> +The changes staged for `hello.c` and `hello.h` are not included
> +in the resulting commit. However, their changes are not lost --
> +they are still staged and merely held back. After the above
> +sequence, if you do:
> +
> +------------
> +$ git commit
> +------------
> +
> +this second commit would record the changes to `hello.c` and
> +`hello.h` as expected.
> +
> +After a merge (initiated by either gitlink:git-merge[1] or
> +gitlink:git-pull[1]) stops because of conflicts, cleanly merged
> +paths are already staged to be committed for you, and paths that
> +conflicted are left in unmerged state. You would have to first
> +check which paths are conflicting with gitlink:git-status[1]
> +and after fixing them manually in your working tree, you would
> +stage the result as usual with gitlink:git-add[1]:
> +
> +------------
> +$ git status | grep unmerged
> +unmerged: hello.c
> +$ edit hello.c
> +$ git add hello.c
> +------------
> +
> +After resolving conflicts and staging the result, `git ls-files -u`
> +would stop mentioning the conflicted path. When you are done,
> +run `git commit` to finally record the merge:
> +
> +------------
> +$ git commit
> +------------
> +
> +As with the case to record your own changes, you can use `-a`
> +option to save typing. One difference is that during a merge
> +resolution, you cannot use `git commit` with pathnames to
> +alter the order the changes are committed, because the merge
> +should be recorded as a single commit. In fact, the command
> +refuses to run when given pathnames (but see `-i` option).
> +
> +
> +ENVIRONMENT VARIABLES
> +---------------------
> +The command specified by either the VISUAL or EDITOR environment
> +variables is used to edit the commit log message.
> +
> +HOOKS
> +-----
> +This command can run `commit-msg`, `pre-commit`, and
> +`post-commit` hooks. See link:hooks.html[hooks] for more
> +information.
I'd add (with links):
SEE ALSO
--------
git-add, git-rm, git-mv, git-merge, git-commit-tree
Otherwise very good.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.4.2
From: Junio C Hamano @ 2006-12-09 21:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.4.2 has been available at
the usual places for a few days, but vger seems to have eaten
the message I sent out, so here is a resend:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4.2-1.$arch.rpm (RPM)
This contains a handful fixes since 1.4.4.1; nothing earth
shattering.
----------------------------------------------------------------
Changes since v1.4.4.1 are as follows:
Alex Riesen (1):
git-blame: fix rev parameter handling.
Andy Parkins (2):
Increase length of function name buffer
Document git-repo-config --bool/--int options.
Eric Wong (4):
git-svn: error out from dcommit on a parent-less commit
git-svn: correctly handle revision 0 in SVN repositories
git-svn: preserve uncommitted changes after dcommit
git-svn: avoid fetching files twice in the same revision
Johannes Schindelin (1):
git-mv: search more precisely for source directory in index
Junio C Hamano (5):
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
git-reset to remove "$GIT_DIR/MERGE_MSG"
René Scharfe (1):
archive-zip: don't use sizeof(struct ...)
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-09 21:10 UTC (permalink / raw)
To: Tilman Sauerbeck; +Cc: git
In-Reply-To: <20061209204413.GA1482@code-monkey.de>
Tilman Sauerbeck <tilman@code-monkey.de> writes:
> Junio C Hamano [2006-12-06 13:18]:
>> * The 'maint' branch has produced a new release 1.4.4.2
>
> Any reason why this wasn't announced?
Well, vger seems to have ate the message.
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Jakub Narebski @ 2006-12-09 20:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612091442470.2630@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 8 Dec 2006, Junio C Hamano wrote:
[...]
>> Another reason I described the merge workflow is it would become
>> much less clear why --only is useless in merge situation if the
>> reader does not know that a conflicted merge stages the
>> auto-resolved changes.
>
> Sure, but the whole merge concept might still not make any sense at the
> moment the user is learning about commit. In other words, the "commit"
> documentation must not depend on the "merge" concept. It should rather
> be the other way around, i.e. the "merge" documentation can easily
> depend on the "commit" documentation.
>
> Just like I carefully avoided talking about "commit -a" in the git-add
> man page to avoid circular conceptual dependencies. But obviously the
> git-commit man page must talk about the "add" concept.
>
> This way you get a progressive knowledge base with git-add which pretty
> much stands on its own, then you move to git-commit that depends on
> git-add, then you move to merging and resolving conflicts that depend on
> git-commit. And so without being distracted by concepts you don't need
> to know just yet along the way.
IMVHO for reference documentation (and manpages for commands are such
documentation) it is more important to be complete, than to be
self-contained and without circular conceptual dependencies. The latter
(and defining things before using it) is more important for things like
tutorial or quickstart.
If one is not doing merge then one can skip the talk about merges. If one
git-commit complains about using --only (because of merge), one would
rather search for information in git-commit(1), not git-merge(1) or
git-pull(1); well, the merge might be result of git-checkout -m.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (stable)
From: Tilman Sauerbeck @ 2006-12-09 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt54yb8d.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Junio C Hamano [2006-12-06 13:18]:
> * The 'maint' branch has produced a new release 1.4.4.2
Any reason why this wasn't announced?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am
From: Junio C Hamano @ 2006-12-09 20:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1165613397460-git-send-email-normalperson@yhbt.net>
I looked at your previous 5-patch series but will replace with
this updated 2-patch series.
The rerere command started its life as a mere helper for
Porcelains, but with 'status' and 'diff', you are making it
somewhat Porcelain-ish. I still have not decided myself, but I
think we probably would want to treat this as a Porcelain and
give a bit of usability to it, so what I've committed has two
changes from your version:
(1) 'diff' without @ARGV defaults to '-u';
(2) running rerere with unknown sub command die()s instead of
silently exiting with 0.
The difference between your previous 5-patch series and this
round raises an interesting issue.
You used to have a safety valve in git-commit to prevent users
from running it while rebase/am is in progress, which I imagine
would be a common mistake.
There are three commands in git suite that a user would use to
eventually make new commits, out of something other than what
was edited and prepared in the working tree, that can stop in
the middle.
(1) git-am is used to make new commits from e-mailed patches,
and stops in the middle when a patch does not apply.
"git-am --resolved/--skip" are the ways to continue.
(2) git-rebase is used to rewrite the history of a branch, and
stops in the middle when a patch does not apply or merge
conflicts. "git-rebase --continue/--skip/--abort" are
possible exits [*1*].
(3) git-pull/git-merge are used to make merge commits with
another branch, and stops in the middle when it conflicts.
Possible exits are "git commit" or "git reset".
Now, I am not going to propose to fix this inconsistency and
forbid use of "git commit" to resolve "git-merge" (instead, the
user would say "git-merge --resolved/--abort"). As the workflow
goes, these are very different operations and the user is often
well aware which workflow is in progress; having different
commands for different exit route is fine.
But in order to implement the safety valve like you did cleanly,
we should first have an enumeration of states (the above is a
subset --- there is the "base state" in which you are working
towards a commit based on HEAD, which is obviously concluded
with a "git commit", and "bisect in progress") and make it easy
for commands to communicate what state the working tree is in.
That would also help 'git-explain'.
[Footnote]
*1* Resuming rebase was much worse before Sean updated it with
commit 031321c6 to hide that it uses git-am as its backend,
which is purely its implementation detail.
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Nicolas Pitre @ 2006-12-09 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsatelvv.fsf@assigned-by-dhcp.cox.net>
On Fri, 8 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Frankly I feel unconfortable with this.
> >
> > 1) too many examples.
> >
> > Yes, examples are good, but somehow there is something in the current
> > text that make me feel they are not providing the clarification they
> > should. Dunno... I think I'd still push them after option list.
>
> Hmmm. I was merely trying to respond with recent requests on
> the list (might have been #git log) to make common usage
> examples more prominent. While I feel that following the UNIXy
> manpage tradition to push examples down is the right thing to
> do, you and I are not the primary audience of Porcelain
> manpages, so...
Sure, but sometimes too much is just as bad as not enough. And given
the amount of text in your version I feel the essence of the information
gets dilluted too much.
> > 2) explanation of how to resolve and commit a conflicting merge should
> > really be found in git-merge.txt not in git-commit.txt.
> >
> > It feels a bit awkward to suddenly start talking about git ls-files and
> > merge here.
>
> I agree that it looks a bit out of place; the primary reason I
> talked about the merge was to make it clear that a conflicted
> merge will still stage the changes for cleanly auto-resolved
> paths. In other words, it makes me feel uneasy that there is no
> mention of it in the list in your version that follows this
> sentence:
>
> > +... All changes
> > +to be committed must be explicitly identified using one of the following
> > +methods:
>
> It would make me happier if you had, at the end of enumeration,
> something like:
>
> Note that the contents of the paths that resolved
> cleanly by a conflicted merge are automatically staged
> for the next commit; you still need to explicitly
> identify what you want in the resulting commit using one
> of the above methods before concluding the merge.
But why couldn't this be in the git-merge man page instead? That is
precisely the sort of addition that makes me feel like we're trying to
say too much at the same time. When in the context of learning how
"commit" works, it is certainly not necessary to talk about how "merge"
works. That should really be mentioned in the "merging" documentation
(with a link to git-commit for more options on commit).
> Another reason I described the merge workflow is it would become
> much less clear why --only is useless in merge situation if the
> reader does not know that a conflicted merge stages the
> auto-resolved changes.
Sure, but the whole merge concept might still not make any sense at the
moment the user is learning about commit. In other words, the "commit"
documentation must not depend on the "merge" concept. It should rather
be the other way around, i.e. the "merge" documentation can easily
depend on the "commit" documentation.
Just like I carefully avoided talking about "commit -a" in the git-add
man page to avoid circular conceptual dependencies. But obviously the
git-commit man page must talk about the "add" concept.
This way you get a progressive knowledge base with git-add which pretty
much stands on its own, then you move to git-commit that depends on
git-add, then you move to merging and resolving conflicts that depend on
git-commit. And so without being distracted by concepts you don't need
to know just yet along the way.
^ permalink raw reply
* Re: doc bug?
From: Junio C Hamano @ 2006-12-09 18:42 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <elc64k$t4i$1@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> while messing with GIT's build system, I got
>
> **
> asciidoc -b docbook -d manpage -f ../Documentation/asciidoc.conf ../Documentation/git-tools.txt
> ERROR: git-tools.txt: line 2: malformed manpage title
> ERROR: git-tools.txt: line 6: first section must be named NAME
> ERROR: git-tools.txt: line 9: malformed NAME section body
> FAILED: /home/lilydev/vc/git/Documentation/git-tools.txt: line 9: unexpected error:
That is interesting. git-tools is listed on ARTICLES which is
excluded from MAN1_TXT so the Makefile should not even try to
run the above commandline that says 'manpage'.
At least that is what our Makefile intends to do.
So that means you may have found a bug in our Makefile, or your
make (by the way I think we pretty much requires GNU make to
build git), or perhaps both.
But I do not see an obvious breakage in our Makefile in this
area...
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 18:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, Jakub Narebski, Martin Langhoff, Git Mailing List,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <Pine.LNX.4.64.0612090957360.3516@woody.osdl.org>
Linus Torvalds wrote:
>
> So there's probably tons of room for making this more efficient: using a
> newer gitweb, packing refs, using the cgi cache thing.. It sounds like
> what it really needs is just somebody with the competence and time to be
> willing to step up and maintain gitweb on kernel.org...
>
Indeed. We have a lot of projects on kernel.org which are like this:
not at all conceptually hard, but a huge time commitment for Doing It
Right[TM]. This is why I sometimes think that it would be a Good Thing
to get paid staff for kernel.org, although I was hoping to defer the
need for that until at least we have our 501(c)3 paperwork done, which
looks like mid-2007 at this point (assuming no further delays.)
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-09 18:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jakub Narebski, Martin Langhoff, Git Mailing List, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457AAF31.2050002@garzik.org>
On Sat, 9 Dec 2006, Jeff Garzik wrote:
>
> It is. At least for kernel.org, the issue isn't that CGI is expensive, its
> that I/O is expensive.
Note that if we had a new gitweb, we could also used the packed refs.
Those help CPU usage, but they actually help IO patterns more, exactly
because they avoid all the seeking around in the filesystem.
So with packed refs, there's no need to go from directory lookup to inode
lookup to data lookup to object lookup for *each* ref - you can do the
"packed-refs" lookup _once_ (which obviously does the dir->inode->data),
and you don't need to do the object lookup at all.
Of course, gitweb will then end up doing the object lookup anyway (because
of getting the dates etc for refs), but if you have packed-refs and a
reasonably packed repository, that should still really cut down on IO in a
big way.
So there's probably tons of room for making this more efficient: using a
newer gitweb, packing refs, using the cgi cache thing.. It sounds like
what it really needs is just somebody with the competence and time to be
willing to step up and maintain gitweb on kernel.org...
^ permalink raw reply
* Re: doc bug?
From: Han-Wen Nienhuys @ 2006-12-09 18:04 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30612090930o7b856223ub87746181f958b7c@mail.gmail.com>
Jonas Fonseca escreveu:
>> is this a new problem? I'm on FC6, with asciidoc 7.0.2
>
> The git-tools.txt document is not intended to be a man page
So why does the doc try make one for it? This is a bug, no?
--
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Marco Costalba @ 2006-12-09 17:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20061209173703.GA12373@steel.home>
On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:
> Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:
>
> > P.S: I have no way to exec the script in fancy ways, I can just start
> > it and get is PID.
>
> Which is "fancy" enough. What do you mean "start"? Starting a new
> process usually and notably involves forking and execing (even if the
> first thing to exec will be your shell).
>
>
By 'start' I mean it is done inside Qt QProcess class back box ;-)
Anyway I have written an homegrown 'wanna be hacker' launching script:
git rev-list --header --boundary --parents --topo-order HEAD >
/tmp/qgit_136224752.txt &
echo $!
wait
With this I can get the pid of git-rev-list from my QProcess interface
so to be able to kill it when needed with another command ('kill'
BTW).
I have googled around and it seems that 'echo $!' and 'wait' _should_
be portable among many shell, please correct me if'm wrong or if the
approach is failing (I already know it's ugly ;-) )
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Alex Riesen @ 2006-12-09 17:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612090716p215167b9r2277b09c09b18894@mail.gmail.com>
Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:
> So how can I write the script to be sure that when stopped, it will
> kill all his childern?
Strictly speaking: you can't. Anything you'd try will either be not
portable or involve quiet complex dependencies (like perl).
Are you sure you can't control each process independently?
Speaking not so strictly, you can use a script engine which supports
either signal handling or exit notification (i.e. sh has traps and
perl has %SIG and END{}). It's unsafe, ugly and not quiet portable to
that other operating system, but it often works and is (ab)used.
> P.S: I have no way to exec the script in fancy ways, I can just start
> it and get is PID.
Which is "fancy" enough. What do you mean "start"? Starting a new
process usually and notably involves forking and execing (even if the
first thing to exec will be your shell).
^ permalink raw reply
* Re: doc bug?
From: Jonas Fonseca @ 2006-12-09 17:30 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <elc64k$t4i$1@sea.gmane.org>
On 12/8/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Hi,
Hello,
> while messing with GIT's build system, I got
>
> **
> asciidoc -b docbook -d manpage -f ../Documentation/asciidoc.conf ../Documentation/git-tools.txt
> ERROR: git-tools.txt: line 2: malformed manpage title
> ERROR: git-tools.txt: line 6: first section must be named NAME
> ERROR: git-tools.txt: line 9: malformed NAME section body
> FAILED: /home/lilydev/vc/git/Documentation/git-tools.txt: line 9: unexpected error:
> [traceback]
> **
>
> is this a new problem? I'm on FC6, with asciidoc 7.0.2
The git-tools.txt document is not intended to be a man page
(there is no git-tools command) so it cannot be converted into
a man page. You should be able to make a HTML document
out of it, although the AsciiDoc formatting is not "optimal".
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 17:27 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091802.12810.jnareb@gmail.com>
Jakub Narebski wrote:
> Jeff Garzik wrote:
>> Jakub Narebski wrote:
>
>>> As I said, I'm not talking (at least now) about saving generated HTML
>>> output. This I think is better solved in caching engine like Squid can
>>> be. Although even here some git specific can be of help: we can invalidate
>>> cache on push, and we know that some results doesn't ever change (well,
>>> with exception of changing output of gitweb).
>> It depends on how creatively you think ;-)
>>
>> Consider generating static HTML files on each push, via a hook, for many
>> of the toplevel files. The static HTML would then link to the CGI for
>> further dynamic querying of the git database.
>
> You mean that the links in this pre-generated HTML would be to CGI
> pages?
Yes, they must be. Otherwise, the gitweb interface changes.
You don't want to pre-generate HTML for every possible git query, that
would cause an explosion of data.
Both the HTML generator and CGI would need to know which pages were
pre-generated and which are not.
Jeff
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 17:02 UTC (permalink / raw)
To: Jeff Garzik
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457ACBA1.4090007@garzik.org>
Jeff Garzik wrote:
> Jakub Narebski wrote:
>> As I said, I'm not talking (at least now) about saving generated HTML
>> output. This I think is better solved in caching engine like Squid can
>> be. Although even here some git specific can be of help: we can invalidate
>> cache on push, and we know that some results doesn't ever change (well,
>> with exception of changing output of gitweb).
>
> It depends on how creatively you think ;-)
>
> Consider generating static HTML files on each push, via a hook, for many
> of the toplevel files. The static HTML would then link to the CGI for
> further dynamic querying of the git database.
You mean that the links in this pre-generated HTML would be to CGI
pages?
>> What can be _easily_ done:
>> * Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
>> page; this leads to around 3 times faster summary page.
>
> This re-opens the question mentioned earlier, is Kay (or anyone?) still
> actively maintaining gitweb on k.org?
By the way, thanks to Martin Waitz it is much easier to install gitweb.
I for example use the following script to test changes I have made to gitweb:
-- >8 --
#!/bin/bash
BINDIR="/home/local/git"
function make_gitweb()
{
pushd "/home/jnareb/git/"
make GITWEB_PROJECTROOT="/home/local/scm" \
GITWEB_CSS="/gitweb/gitweb.css" \
GITWEB_LOGO="/gitweb/git-logo.png" \
GITWEB_FAVICON="/gitweb/git-favicon.png" \
bindir=$BINDIR \
gitweb/gitweb.cgi
popd
}
function copy_gitweb()
{
cp -fv /home/jnareb/git/gitweb/gitweb.{cgi,css} /home/local/gitweb/
}
make_gitweb
copy_gitweb
# end of gitweb-update.sh
-- >8 --
>> * Perhaps using projects list file (which can be now generated by gitweb)
>> instead of scanning directories and stat()-ing for owner would help
>> with time to generate projects lis page
>
> This could be statically generated by a robot. I think everybody would
> shrink in horror if a human needed to maintain such a file.
Gitweb can generate this file. The problem is that one would have to
temporary turn off using index file. This can be done by having the
following gitweb_list_projects.perl file:
-- >8 --
#!/usr/bin/perl
$projects_list = "";
-- >8 --
then use the following invocation to generate project index file:
$ GATEWAY_INTERFACE="CGI/1.1" HTTP_ACCEPT="*/*" REQUEST_METHOD="GET" \
GITWEB_CONFIG=gitweb_list_projects.perl QUERY_STRING="a=project_index" \
gitweb.cgi
--
Jakub Narebski
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 16:26 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <46a038f90612082134x38be9c8dgca6fe60c087bf100@mail.gmail.com>
Martin Langhoff wrote:
> On 12/9/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> Martin Langhoff wrote:
>> > I posted separately about those. And I've been mulling about whether
>> > the thundering herd is really such a big problem that we need to
>> > address it head-on.
>>
>> Uhm... yes it is.
>
> Got some more info, discussion points or links to stuff I should read
> to appreciate why that is? I am trying to articulate why I consider it
> is not a high-payoff task, as well as describing how to tackle it.
>
> To recap, the reasons it is not high payoff is that:
>
> - the main benefit comes from being cacheable and able to revalidate
> the cache cheaply (with the ETags-based strategy discussed above)
> - highly distributed caches/proxies means we'll seldom see a true
> cold cache situation
> - we have a huge set of URLs which are seldom hit, and will never see
> a thundering anything
> - we have a tiny set of very popular URLs that are the key target for
> the thundering herd - (projects page, summary page, shortlog, fulllog)
> - but those are in the clear as soon as the caches are populated
>
> Why do we have to take it head-on? :-)
>
Because the primary failure scenario is timeout on the common queries
due to excess parallel invocations under high I/O load resulting in
catastrophic failure.
^ permalink raw reply
* Re: [PATCH] Add branch.*.merge warning and documentation update
From: Santi Béjar @ 2006-12-09 16:14 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200612090228.26722.Josef.Weidendorfer@gmx.de>
On 12/9/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> This patch clarifies the meaning of the branch.*.merge option.
> Previously, if branch.*.merge was specified but did not match any
> ref, the message "No changes." was not really helpful regarding
> the misconfiguration. This patch adds a warning for this.
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Acked-by: Santi Béjar <sbejar@gmail.com>
And thanks for the patch.
^ permalink raw reply
* Easy shell question: how to make a script killing all his childs when killed?
From: Marco Costalba @ 2006-12-09 15:16 UTC (permalink / raw)
To: Git Mailing List
Ok. I am really bad at scripting, so perhaps my question is very silly, but...
I create and run a script with the content:
git rev-list --header --boundary --parents --topo-order 2229ff5c7c >
/tmp/qgit_135902672.txt
Then I kill the script while it's running, but his child
(git-rev-list) continues to run in background and I would like to stop
it either.
So how can I write the script to be sure that when stopped, it will
kill all his childern?
Thanks
Marco
P.S: I have no way to exec the script in fancy ways, I can just start
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 14:43 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091437.01183.jnareb@gmail.com>
Jakub Narebski wrote:
> Sending Last-Modified: should be easy; sending ETag needs some consensus
> on the contents: mainly about validation. Responding to If-Modified-Since:
> and If-None-Match: should cut at least _some_ of the page generating time.
Definitely.
> As I said, I'm not talking (at least now) about saving generated HTML
> output. This I think is better solved in caching engine like Squid can
> be. Although even here some git specific can be of help: we can invalidate
> cache on push, and we know that some results doesn't ever change (well,
> with exception of changing output of gitweb).
It depends on how creatively you think ;-)
Consider generating static HTML files on each push, via a hook, for many
of the toplevel files. The static HTML would then link to the CGI for
further dynamic querying of the git database.
> What can be _easily_ done:
> * Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
> page; this leads to around 3 times faster summary page.
This re-opens the question mentioned earlier, is Kay (or anyone?) still
actively maintaining gitweb on k.org?
> * Perhaps using projects list file (which can be now generated by gitweb)
> instead of scanning directories and stat()-ing for owner would help
> with time to generate projects lis page
This could be statically generated by a robot. I think everybody would
shrink in horror if a human needed to maintain such a file.
> What can be quite easy incorporated into gitweb:
> * For immutable pages set Expires: or Cache-Control: max-age (or both)
> to infinity
nice!
> * Generate Last-Modified: for those views where it can be calculated,
> and respond with 304 Not Modified as soon as it can.
agreed
> What can be easily done using caching engine:
> * Select top 10 of common queries, and cache them, invalidating cache on push
> (depending on query: for example invalidate project list on push to any
> project, invalidate RSS/Atom feed and summary pages only on push to specific
> project) - can be done with git hooks.
Or simply generate regular filesystem files into the webspace, as
triggered by a hook. Let the standard filesystem mirroring/caching work
its magic.
Jeff
^ permalink raw reply
* Re: RFC PATCH: support for default remote in StGIT
From: Yann Dirson @ 2006-12-09 13:36 UTC (permalink / raw)
To: Pavel Roskin; +Cc: "Catalin Marinas catalin.marinas", git
In-Reply-To: <1165656205.2816.47.camel@portland.localdomain>
Hi Pavel,
This is quite related to the subject of the "Handling of branches in
stgit" thread I launched recently (Nov 30th).
On Sat, Dec 09, 2006 at 04:23:25AM -0500, Pavel Roskin wrote:
> It's very important for me to have default remote support in StGIT. I'm
> trying to track different Linux branches, and I don't want to remember
> what branch I'm on when I run "stg pull".
Right, that's the main problem with the current implementation.
> One approach is to leave the default remote selection completely to git.
> The downside is that StGIT prints the remote it's pulling from. Now
> StGIT will have to print common words that it's pulling something. Or
> maybe it shouldn't print anything?
It could just print a generic message and let GIT print out
the details.
> Also, git-pull doesn't allow to specify the refspec without the remote.
> This limitation seems artificial to me, but we have to pass this
> limitation to the StGIT users.
In which situtation do you need to pass a refspec ? I thought all
necessary refspecs should already be part of a remote's definition.
> The positive side if that StGIT is completely unaware of the word
> "origin", and any changes in git handling of the default remote will
> propagate to StGIT immediately.
Indeed.
> The other approach is to calculate the default remote in StGIT. This
> would allow StGIT to tell the user where it's pulling from.
Doing so would probably require to teach StGIT about every new way of
fetching a branch (we already have 3 ways, as outlined in my initial
mail). OTOH, it may be the only way to present the user with a
uniform way of working, independently of the way we update the parent
branch.
Indeed, we may just want to distinguish whether the parent branch is a
remote one or not. Then if it's a remote one, git-fetch already has
enough info to do its work updating the parent branch (whether using
.git/remotes or .git/branches). If it's not a remote branch, there's
just nothing to do at this step.
Then, we just have to "pop -a" and move the stack base, without
relying on "pull". That would also transparently give support for
branching off a non-forwarding branch (like git's "next" and "pu", or
like any stgit managed branch). Would anyone miss the "git-pull" call ?
Best regards,
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 13:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <457AAF31.2050002@garzik.org>
Jeff Garzik wrote:
> Jakub Narebski wrote:
>> In addition to setting either Expires: header or Cache-Control: max-age
>> gitweb should also set Last-Modified: and ETag headers, and also
>> probably respond to If-Modified-Since: and If-None-Match: requests.
>>
>> Would be worth implementing this?
>
> IMO yes, since most major browsers, caches, and spiders support these
> headers.
Sending Last-Modified: should be easy; sending ETag needs some consensus
on the contents: mainly about validation. Responding to If-Modified-Since:
and If-None-Match: should cut at least _some_ of the page generating time.
If ETag can be calculated on URL alone, then we can cut If-None-Match:
just at beginning of script.
>> For some pages ETag is natural; for other Last-Modified: would be more
>> natural.
>
> Yes, a good point to note.
>
>> Usualy you can compare ETags base on URL alone.
>
> Mostly true: you must also consider HTTP_ACCEPT
Well, yes, ETag is HTTP/1.1 header.
>> Wouldn't it be simplier to just set Last-Modified: header (and check
>> it?)
>
> That would be a good start, and suffice for many cases. If the CGI can
> simply stat(2) files rather than executing git-* programs, that would
> increase efficiency quite a bit.
As I said, I'm not talking (at least now) about saving generated HTML
output. This I think is better solved in caching engine like Squid can
be. Although even here some git specific can be of help: we can invalidate
cache on push, and we know that some results doesn't ever change (well,
with exception of changing output of gitweb).
> A core problem with cache hints via HTTP headers (last-modified, etc.)
> is that you don't achieve caching across multiple clients, just across
> repeated queries from the same client (or caching proxy).
>
> At least for the RSS/Atom feeds and the git main page, it makes no sense
> to regenerate that data repeatedly.
>
> Internally, gitweb would need to do a stat() on key files, and return
> pre-generated XML for the feeds if the stat() reveals no changes. Ditto
> for the front page.
I'm not sure if it is worth implementing in gitweb, or is it better left
to caching engine. With the projects list page and summary page there is
additional problem with relative dates, although this can be solved using
Jonas Fonseca idea of using absolute dates in the page and using ECMAScript
(JavaScript) to convert them to relative: on load, and perhaps on timer ;-)
What can be _easily_ done:
* Use post 1.4.4 gitweb, which uses git-for-each-ref to generate summary
page; this leads to around 3 times faster summary page.
* Perhaps using projects list file (which can be now generated by gitweb)
instead of scanning directories and stat()-ing for owner would help
with time to generate projects lis page
What can be quite easy incorporated into gitweb:
* For immutable pages set Expires: or Cache-Control: max-age (or both)
to infinity
* Calculate hash+action based ETag at least for those actions where it is
easy, and respond with 304 Not Modified as soon as it can.
This might require some code reorganization to not begin writing output
before calculating ETag and ETag comparison (If-Match, If-None-Match).
* Generate Last-Modified: for those views where it can be calculated,
and respond with 304 Not Modified as soon as it can.
What can be easily done using caching engine:
* Select top 10 of common queries, and cache them, invalidating cache on push
(depending on query: for example invalidate project list on push to any
project, invalidate RSS/Atom feed and summary pages only on push to specific
project) - can be done with git hooks.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Han-Wen Nienhuys @ 2006-12-09 13:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b7qi0b4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> Eric Wong <normalperson@yhbt.net> writes:
>
>> Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>>> git-sh-setup isn't a 'normal' binary, in that it should be called by
>>> bash only and not run in a subshell. Therefore, it should not be installed
>>> in a executable directory, but rather in $prefix/share/git-core/
>> This seems to break existing hooks, or at least old repositories can
>> be stuck using an old version of git-sh-setup in those hooks.
>
> Honestly speaking, I do not think this patch is worth it.
> People who care deeply enough should just use gitexecdir that is
> separate from bindir.
And how about coding the path of git-sh-setup (in <prefix>/bin/git-sh-setup)
in the shell scripts? This will ensure that the sh-setup is the one
from the right package, but still retain backward compatibility for
scripts.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 12:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Langhoff, Git Mailing List, Linus Torvalds, H. Peter Anvin,
Rogan Dawes, Kernel Org Admin
In-Reply-To: <200612091251.16460.jnareb@gmail.com>
Jakub Narebski wrote:
> First, it would (and could) work only for serving gitweb over mod_perl.
> I'm not sure if overhead with IPC and complications implementing are
> worth it: this perhaps be better solved by caching engine.
It is. At least for kernel.org, the issue isn't that CGI is expensive,
its that I/O is expensive.
> In addition to setting either Expires: header or Cache-Control: max-age
> gitweb should also set Last-Modified: and ETag headers, and also
> probably respond to If-Modified-Since: and If-None-Match: requests.
>
> Would be worth implementing this?
IMO yes, since most major browsers, caches, and spiders support these
headers.
> For some pages ETag is natural; for other Last-Modified: would be more
> natural.
Yes, a good point to note.
> Usualy you can compare ETags base on URL alone.
Mostly true: you must also consider HTTP_ACCEPT
> Wouldn't it be simplier to just set Last-Modified: header (and check
> it?)
That would be a good start, and suffice for many cases. If the CGI can
simply stat(2) files rather than executing git-* programs, that would
increase efficiency quite a bit.
A core problem with cache hints via HTTP headers (last-modified, etc.)
is that you don't achieve caching across multiple clients, just across
repeated queries from the same client (or caching proxy).
At least for the RSS/Atom feeds and the git main page, it makes no sense
to regenerate that data repeatedly.
Internally, gitweb would need to do a stat() on key files, and return
pre-generated XML for the feeds if the stat() reveals no changes. Ditto
for the front page.
> P.S. Can anyone post some benchmark comparing gitweb deployed under
> mod_perl as compared to deployed as CGI script? Does kernel.org use
> mod_perl, or CGI version of gitweb?
CGI version of gitweb.
But again, mod_perl vs. CGI isn't the issue.
Jeff
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-09 12:15 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: Andreas Ericsson, Shawn Pearce, Git Mailing List
In-Reply-To: <f2b55d220612081210u6ec3e95ciec6665a6b5e6a827@mail.gmail.com>
On 12/8/06, Michael K. Edwards <medwards.linux@gmail.com> wrote:
> There is a very handy solution to this problem called "tmpfs". It
> should already be mounted at /tmp. Put tmp.txt there and your problem
> will go away.
>
Thanks Michael,
It seems to work! patch pushed.
Marco
P.S: I've looked again to Shawn idea (and code) of linking qgit
against libgit.a but I found these two difficult points:
- traverse_commit_list(&revs, show_commit, show_object) is blocking,
i.e. the GUI will stop responding for few seconds while traversing the
list. This is easily and transparently solved by the OS scheduler if
an external process is used for git-rev-list. To solve this in qgit I
have two ways: 1) call QEventLoop() once in a while from inside
show_commit()/ show_object() to process pending events 2) Use a
separate thread (QThread class). The first idea is not nice, the
second opens a whole a new set of problems and it's a big amount of
not trivial new code to add.
- traverse_commit_list() having an internal state it's not
re-entrant. git-rev-list it's used to load main view data but also
file history in another tab, and the two calls _could_ be ran
concurrently. With external process I simply run two instances of
DataLoader class and consequently two external git-rev-list processes,
^ 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