* [PATCH] Added documentation for few missing options.
From: Jon Loeliger @ 2005-12-06 5:13 UTC (permalink / raw)
To: git
More $ shell prompts in examples.
Minor English grammar improvements.
Added a few "See Also"s.
Use back-ticks on more command examples.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/git-checkout-index.txt | 78 +++++++++++++++++++++-------------
Documentation/git-init-db.txt | 27 ++++++++++--
Documentation/git-prune-packed.txt | 11 +++--
Documentation/git-read-tree.txt | 74 ++++++++++++++++++--------------
Documentation/git-update-index.txt | 20 +++++++--
Documentation/git-write-tree.txt | 14 +++---
6 files changed, 142 insertions(+), 82 deletions(-)
applies-to: 0e248e1eed0d5aedd0054cf273df03460047ebc9
4baf91676c2462796137e93917c75f2e14ebb877
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 5bff486..97eef22 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -45,53 +45,71 @@ OPTIONS
The order of the flags used to matter, but not anymore.
-Just doing "git-checkout-index" does nothing. You probably meant
-"git-checkout-index -a". And if you want to force it, you want
-"git-checkout-index -f -a".
+Just doing `git-checkout-index` does nothing. You probably meant
+`git-checkout-index -a`. And if you want to force it, you want
+`git-checkout-index -f -a`.
Intuitiveness is not the goal here. Repeatability is. The reason for
-the "no arguments means no work" thing is that from scripts you are
-supposed to be able to do things like:
+the "no arguments means no work" behavior is that from scripts you are
+supposed to be able to do:
- find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+----------------
+$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+----------------
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point.
-To update and refresh only the files already checked out:
-
- git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
-
-Oh, and the "--" is just a good idea when you know the rest will be
-filenames. Just so that you wouldn't have a filename of "-a" causing
-problems (not possible in the above example, but get used to it in
-scripting!).
-
-The prefix ability basically makes it trivial to use
-git-checkout-index as an "export as tree" function. Just read the
-desired tree into the index, and do a
-
- git-checkout-index --prefix=git-export-dir/ -a
-
-and git-checkout-index will "export" the index into the specified
+The `--` is just a good idea when you know the rest will be filenames;
+it will prevent problems with a filename of, for example, `-a`.
+Using `--` is probably a good policy in scripts.
+
+
+EXAMPLES
+--------
+To update and refresh only the files already checked out::
++
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+
+Using `git-checkout-index` to "export an entire tree"::
+ The prefix ability basically makes it trivial to use
+ `git-checkout-index` as an "export as tree" function.
+ Just read the desired tree into the index, and do:
++
+----------------
+$ git-checkout-index --prefix=git-export-dir/ -a
+----------------
++
+`git-checkout-index` will "export" the index into the specified
directory.
++
+The final "/" is important. The exported name is literally just
+prefixed with the specified string. Contrast this with the
+following example.
+
+Export files with a prefix::
++
+----------------
+$ git-checkout-index --prefix=.merged- Makefile
+----------------
++
+This will check out the currently cached copy of `Makefile`
+into the file `.merged-Makefile`.
-NOTE The final "/" is important. The exported name is literally just
-prefixed with the specified string, so you can also do something like
-
- git-checkout-index --prefix=.merged- Makefile
-
-to check out the currently cached copy of `Makefile` into the file
-`.merged-Makefile`
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
+
Documentation
--------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+Documentation by David Greaves,
+Junio C Hamano and the git-list <git@vger.kernel.org>.
+
GIT
---
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index ef1826a..4486f0c 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -8,7 +8,14 @@ git-init-db - Creates an empty git repos
SYNOPSIS
--------
-'git-init-db'
+'git-init-db' [--template=<template_directory>]
+
+
+OPTIONS
+-------
+--template=<template_directory>::
+ Provide the directory in from which templates will be used.
+
DESCRIPTION
-----------
@@ -16,14 +23,26 @@ This simply creates an empty git reposit
and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
-If the 'GIT_DIR' environment variable is set then it specifies a path
+If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
-If the object storage directory is specified via the 'GIT_OBJECT_DIRECTORY'
+If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
-"git-init-db" won't hurt an existing repository.
+`git-init-db` won't hurt an existing repository.
+
+
+EXAMPLES
+--------
+
+Start a new git repository for an existing code base::
++
+----------------
+$ cd /path/to/my/codebase
+$ git-init-db
+----------------
+
Author
diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt
index 8d96a91..37c53a9 100644
--- a/Documentation/git-prune-packed.txt
+++ b/Documentation/git-prune-packed.txt
@@ -9,19 +9,22 @@ residing in a pack file.
SYNOPSIS
--------
-'git-prune-packed'
+'git-prune-packed' [-n]
+
DESCRIPTION
-----------
-This program search the GIT_OBJECT_DIR for all objects that currently exist in
-a pack file as well as the independent object directories.
+This program search the `$GIT_OBJECT_DIR` for all objects that currently
+exist in a pack file as well as the independent object directories.
All such extra objects are removed.
A pack is a collection of objects, individually compressed, with delta
compression applied, stored in a single file, with an associated index file.
-Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.
+Packs are used to reduce the load on mirror systems, backup engines,
+disk storage, etc.
+
OPTIONS
-------
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 6e92e4a..4377362 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -15,15 +15,15 @@ DESCRIPTION
-----------
Reads the tree information given by <tree-ish> into the index,
but does not actually *update* any of the files it "caches". (see:
-git-checkout-index)
+gitlink:git-checkout-index[1])
Optionally, it can merge a tree into the index, perform a
-fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m
-flag. When used with -m, the -u flag causes it to also update
+fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
+flag. When used with `-m`, the `-u` flag causes it to also update
the files in the work tree with the result of the merge.
-Trivial merges are done by "git-read-tree" itself. Only conflicting paths
-will be in unmerged state when "git-read-tree" returns.
+Trivial merges are done by `git-read-tree` itself. Only conflicting paths
+will be in unmerged state when `git-read-tree` returns.
OPTIONS
-------
@@ -56,7 +56,7 @@ OPTIONS
Merging
-------
-If '-m' is specified, "git-read-tree" can perform 3 kinds of
+If `-m` is specified, `git-read-tree` can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
provided.
@@ -65,23 +65,23 @@ provided.
Single Tree Merge
~~~~~~~~~~~~~~~~~
If only 1 tree is specified, git-read-tree operates as if the user did not
-specify '-m', except that if the original index has an entry for a
+specify `-m`, except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
index's stat()s take precedence over the merged tree's).
-That means that if you do a "git-read-tree -m <newtree>" followed by a
-"git-checkout-index -f -u -a", the "git-checkout-index" only checks out
+That means that if you do a `git-read-tree -m <newtree>` followed by a
+`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
the stuff that really changed.
-This is used to avoid unnecessary false hits when "git-diff-files" is
-run after git-read-tree.
+This is used to avoid unnecessary false hits when `git-diff-files` is
+run after `git-read-tree`.
Two Tree Merge
~~~~~~~~~~~~~~
-Typically, this is invoked as "git-read-tree -m $H $M", where $H
+Typically, this is invoked as `git-read-tree -m $H $M`, where $H
is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
fast forward situation).
@@ -94,7 +94,7 @@ the following:
2. The user wants to fast-forward to $M.
-In this case, the "git-read-tree -m $H $M" command makes sure
+In this case, the `git-read-tree -m $H $M` command makes sure
that no local change is lost as the result of this "merge".
Here are the "carry forward" rules:
@@ -141,13 +141,13 @@ operating under the -u flag.
When this form of git-read-tree returns successfully, you can
see what "local changes" you made are carried forward by running
-"git-diff-index --cached $M". Note that this does not
-necessarily match "git-diff-index --cached $H" would have
+`git-diff-index --cached $M`. Note that this does not
+necessarily match `git-diff-index --cached $H` would have
produced before such a two tree merge. This is because of cases
18 and 19 --- if you already had the changes in $M (e.g. maybe
-you picked it up via e-mail in a patch form), "git-diff-index
---cached $H" would have told you about the change before this
-merge, but it would not show in "git-diff-index --cached $M"
+you picked it up via e-mail in a patch form), `git-diff-index
+--cached $H` would have told you about the change before this
+merge, but it would not show in `git-diff-index --cached $M`
output after two-tree merge.
@@ -156,18 +156,20 @@ output after two-tree merge.
Each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
-However, when you do "git-read-tree" with three trees, the "stage"
+However, when you do `git-read-tree` with three trees, the "stage"
starts out at 1.
This means that you can do
- git-read-tree -m <tree1> <tree2> <tree3>
+----------------
+$ git-read-tree -m <tree1> <tree2> <tree3>
+----------------
and you will end up with an index with all of the <tree1> entries in
"stage1", all of the <tree2> entries in "stage2" and all of the
<tree3> entries in "stage3".
-Furthermore, "git-read-tree" has special-case logic that says: if you see
+Furthermore, `git-read-tree` has special-case logic that says: if you see
a file that matches in all respects in the following states, it
"collapses" back to "stage0":
@@ -180,7 +182,7 @@ a file that matches in all respects in t
- stage 1 and stage 3 are the same and stage 2 is different take
stage 2 (some work has been done on stage 2)
-The "git-write-tree" command refuses to write a nonsensical tree, and it
+The `git-write-tree` command refuses to write a nonsensical tree, and it
will complain about unmerged entries if it sees a single entry that is not
stage 0.
@@ -220,8 +222,8 @@ populated. Here is an outline of how th
matching "stage1" entry if it exists too. .. all the normal
trivial rules ..
-You would normally use "git-merge-index" with supplied
-"git-merge-one-file" to do this last step. The script
+You would normally use `git-merge-index` with supplied
+`git-merge-one-file` to do this last step. The script
does not touch the files in the work tree, and the entire merge
happens in the index file. In other words, there is no need to
worry about what is in the working directory, since it is never
@@ -239,27 +241,33 @@ This is done to prevent you from losing
changes. To illustrate, suppose you start from what has been
commited last to your repository:
- $ JC=`git-rev-parse --verify "HEAD^0"`
- $ git-checkout-index -f -u -a $JC
+----------------
+$ JC=`git-rev-parse --verify "HEAD^0"`
+$ git-checkout-index -f -u -a $JC
+----------------
You do random edits, without running git-update-index. And then
you notice that the tip of your "upstream" tree has advanced
since you pulled from him:
- $ git-fetch rsync://.... linus
- $ LT=`cat .git/MERGE_HEAD`
+----------------
+$ git-fetch rsync://.... linus
+$ LT=`cat .git/MERGE_HEAD`
+----------------
Your work tree is still based on your HEAD ($JC), but you have
some edits since. Three-way merge makes sure that you have not
added or modified index entries since $JC, and if you haven't,
then does the right thing. So with the following sequence:
- $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
- $ git-merge-index git-merge-one-file -a
- $ echo "Merge with Linus" | \
- git-commit-tree `git-write-tree` -p $JC -p $LT
+----------------
+$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
+$ git-merge-index git-merge-one-file -a
+$ echo "Merge with Linus" | \
+ git-commit-tree `git-write-tree` -p $JC -p $LT
+----------------
-what you would commit is a pure merge between $JC and LT without
+what you would commit is a pure merge between $JC and $LT without
your work-in-progress changes, and your work tree would be
updated to the result of the merge.
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index fdcb8be..e4678cd 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -123,7 +123,9 @@ merging.
To pretend you have a file with mode and sha1 at path, say:
- $ git-update-index --cacheinfo mode sha1 path
+----------------
+$ git-update-index --cacheinfo mode sha1 path
+----------------
'--info-only' is used to register files without placing them in the object
database. This is useful for status-only repositories.
@@ -138,7 +140,9 @@ Examples
--------
To update and refresh only the files already checked out:
- git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
Configuration
@@ -146,12 +150,18 @@ Configuration
The command honors `core.filemode` configuration variable. If
your repository is on an filesystem whose executable bits are
-unreliable, this should be set to 'false'. This causes the
-command to ignore differences in file modes recorded in the
-index and the file mode on the filesystem if they differ only on
+unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
+This causes the command to ignore differences in file modes recorded
+in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
need to use `git-update-index --chmod=`.
+
+See Also
+--------
+gitlink:git-repo-config[1]
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
index abee05f..77e12cb 100644
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -14,19 +14,21 @@ DESCRIPTION
-----------
Creates a tree object using the current index.
-The index must be merged.
+The index must be in a fully merged state.
-Conceptually, "git-write-tree" sync()s the current index contents
+Conceptually, `git-write-tree` sync()s the current index contents
into a set of tree files.
In order to have that match what is actually in your directory right
-now, you need to have done a "git-update-index" phase before you did the
-"git-write-tree".
+now, you need to have done a `git-update-index` phase before you did the
+`git-write-tree`.
+
OPTIONS
-------
--missing-ok::
- Normally "git-write-tree" ensures that the objects referenced by the
- directory exist in the object database. This option disables this check.
+ Normally `git-write-tree` ensures that the objects referenced by the
+ directory exist in the object database. This option disables this
+ check.
Author
------
---
0.99.9j
^ permalink raw reply related
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Junio C Hamano @ 2005-12-06 3:35 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <14404.1133806037@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Junio C Hamano writes:
> - putenv(3) says
> - The string pointed to by string becomes part of the environment,
> - so altering the string changes the environment.
>
> Good catch, thanks. The Solaris man page first says the
> string space is "no longer used", but at the very end warns
> against using an automatic variable. Chalk one up for lousy
> docs.
Same thing for 5.9.
With the "compat update" patch from last night, I managed to
build on a borrowed sparc with Solaris 5.9, but I needed
NO_SETENV myself. I'd like to throw in another Makefile patch
to catch both 5.8 and 5.9 for this, but would appreciate if
people with various vintage of Solaris boxes can give some
inputs before doing that.
This was done with somewhat stripped down configuration. I had
to say NO_EXPAT, libiconv was needed but iconv and openssl were
installed at nonstandard places, python was 2.3 so I also said
PYTHON_PATH and WITH_OWN_SUBPROCESS_PY from the make command
line. But the borrowed box is not what I administer myself, so
I declare victory for now.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-06 3:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Alex Riesen
In-Reply-To: <20051205231203.GG22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Dec 05, 2005 at 09:22:42PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> new file mode 100644
>
> What about compat/util.h or something? Nicer, shorter, and takes
> advantage of this fancy hierarchical namespace "directories" invention.
> ;-)
While I would appreciate a better name, I am afraid that is not a
particularly good one. It is not "compatibility utilities", but
compat things and util things mixed together, so it does not
belong to compat/ directory to begin with. die() and friends
are not about compatibility at all.
^ permalink raw reply
* Re: Wine + GIT
From: Junio C Hamano @ 2005-12-06 2:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, Mike McCormack
In-Reply-To: <4394F173.6000505@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> 5) never ever do
> git-checkout -f HEAD
>
> HEAD should always be a symlink. 'git checkout -f master' is probably
> what you want.
Correct. "git checkout -f HEAD" is a redundant way to say
"I screwed up and would want to revert the mess in my working
tree to my branch head". You do not need to say HEAD; "git
checkout -f" (or "git reset --hard" if you really want to clean
things up) would do.
> 6) For merges with hand-merged conflicts, I could have sworn that either
> a "git commit -a" or 'git-update-index' + 'git commit' was required.
> Maybe I'm wrong, or that has changed?
That has not changed. With the recent 0.99.9l change, I suspect
that the example on the wiki page (without update-index) would
fail to commit -- the index is now left unmerged after a failed
automerge.
The paragraph "Once you have finished editting [sic]..." needs
to be followed by:
git-update-index those paths you hand corrected
git-commit
^ permalink raw reply
* Re: Wine + GIT
From: Jeff Garzik @ 2005-12-06 2:18 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <4394CD68.8020500@codeweavers.com>
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
>
> http://wiki.winehq.org/GitWine
One other comment: http:// is the slowest of all three transports.
git:// (git daemon) is preferred, followed by rsync.
http:// takes forever, comparatively.
Jeff
^ permalink raw reply
* Re: Wine + GIT
From: Jeff Garzik @ 2005-12-06 2:03 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <4394CD68.8020500@codeweavers.com>
Mike McCormack wrote:
> Hi All,
>
> The Wine project has started maintaining a wine.git in parallel to the
> Wine CVS. To introduce Wine developers to GIT, we've put together a
> short introduction on the Wine Wiki on using GIT to maintain patches.
> You can find it at:
> http://wiki.winehq.org/GitWine
Very cool! :)
Comments:
1) I wrote a git howto for kernel hackers, 95% of which applies to other
projects as well: http://linux.yyz.us/git-howto.html
2) The "git-foo" commands are apparently uncool. "git foo ..." is
preferred.
3) replace
git-diff-index -p HEAD
with
git diff HEAD
4) "git commit -a" can often replace git-update-index+git-commit
5) never ever do
git-checkout -f HEAD
HEAD should always be a symlink. 'git checkout -f master' is probably
what you want.
6) For merges with hand-merged conflicts, I could have sworn that either
a "git commit -a" or 'git-update-index' + 'git commit' was required.
Maybe I'm wrong, or that has changed?
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-06 1:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0512052318290.3406@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 5 Dec 2005, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Dec 2005, Daniel Barkalow wrote:
>
> > I think it's an environment thing of some sort, most likely, but it can't
> > be the user; nothing's setuid and I'm only one user.
>
> Can you insert "env > /tmp/env.$$.out", execute both without and with ssh,
> and compare?
Actually, "ls -l /proc/$$/fd" shows that stdin and stdout are sockets with
ssh, pipes with local, and ttys when just running the script.
The hooks probably ought to be run with something different for
stdin/stdout than the connection to the source of the data. /dev/null,
maybe? Or a log file? Maybe dup stderr, which still seems to be going to
the pusher's terminal?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Wine + GIT
From: Mike McCormack @ 2005-12-05 23:29 UTC (permalink / raw)
To: git
Hi All,
The Wine project has started maintaining a wine.git in parallel to the
Wine CVS. To introduce Wine developers to GIT, we've put together a
short introduction on the Wine Wiki on using GIT to maintain patches.
You can find it at:
http://wiki.winehq.org/GitWine
Comments, flames, corrections and additions welcome :)
Mike
^ permalink raw reply
* Re: announce: git browser
From: Petr Baudis @ 2005-12-05 23:26 UTC (permalink / raw)
To: Artem Khodush; +Cc: Git Mailing List
In-Reply-To: <40b2b7d90512041720i65f63ee1pcfe32d2c0c3c357b@mail.gmail.com>
Dear diary, on Mon, Dec 05, 2005 at 02:20:39AM CET, I got a letter
where Artem Khodush <greenkaa@gmail.com> said that...
> On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:
> > * I would find it much nicer if you wouldn't "squeeze" all the day's
> > (except merge) commits together, but left them separate. Possibly a
> > switch to squeeze them, but I'm really not sure if it's even useful to
> > have.
>
> Well it's easy to do, but then, in Linus tree, a single day would not fit
> on my screen :-) So 'squeezed' mode is helpful for me, at least,
> to get big picture at a glance - in git tree, for example, I can see
> the 0.99.5 release branch to begin and end on a single screen.
I see. Well, how useful the big picture is? (Or rather the part of it
you don't get by just looking at the current state.)
> > * The line graphics etc. might be more colourful and prettier. ;-)
>
> And the question is: the colours are assigned to what:
> branches ? authors ? committers ? repositories ?
Branches for easy visual distinguishing of what line is what, I guess.
Coloring based on repositories in particular would be very hard.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Petr Baudis @ 2005-12-05 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen
In-Reply-To: <7voe3vb8fh.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Dec 05, 2005 at 09:22:42PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/git-compat-util.h b/git-compat-util.h
> new file mode 100644
What about compat/util.h or something? Nicer, shorter, and takes
advantage of this fancy hierarchical namespace "directories" invention.
;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Johannes Schindelin @ 2005-12-05 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmnf9px8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 5 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, reading the code I am not satisfied. If there is no template for
> > the config file, it does not test the filemode at all.
>
> I have a feeling that you have not tried the code you are
> arguing against.
Got me right there.
Sorry.
Ciao,
Dscho
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Junio C Hamano @ 2005-12-05 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0512051651050.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The thing that confuses me is that it works when run from ssh or directly,
> but not when run from a local push. I'd expect the two that work to be
> most different.
One suspicion and one suggestion (without knowing exactly where
that suggestion might lead us to).
- your stdout/stderr might be connected to somewhere that your
output gets stuck ("broken pipe"), when your script is run
from the hook.
- your environment might be different from what you are
assuming.
How about doing something like this?
#!/bin/sh
+ exec >/var/tmp/hook-out.$$ 2>/var/tmp/hook-err.$$
+ echo "** env **"
+ env
+ echo "** vars **"
+ i=0
+ for v
+ do
+ echo "$i: $v"
+ i=$(($i+1))
+ done
+ echo "** pwd etc **"
+ pwd
+ id -a
unset GIT_DIR
cd /home/barkalow/auto-working/web
if ! git pull /home/barkalow/git/web.git/
and then next replace the whole thing with:
exec >/dev/null 2>&1
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-05 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0512052138560.6554@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 5 Dec 2005, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Dec 2005, Daniel Barkalow wrote:
>
> > I have the following post-update hook:
> >
> > -----
> > #!/bin/sh
> >
> > unset GIT_DIR
> > cd /home/barkalow/auto-working/web
> > if ! git pull /home/barkalow/git/web.git/
> > then
> > exit 1
> > fi
> > make
> > -----
> >
> > >From that "git pull", I'm getting:
> >
> > /home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
> >
> > It works fine when pushing over ssh,
>
> Maybe it runs as a different user? (Sorry if this sounds dumb, but that's
> exactly the kind of solution I usually find after *days*.)
I think it's an environment thing of some sort, most likely, but it can't
be the user; nothing's setuid and I'm only one user.
The thing that confuses me is that it works when run from ssh or directly,
but not when run from a local push. I'd expect the two that work to be
most different.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-05 21:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051205215059.GC4443@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Dec 05, 2005 21:22:42 +0100:
>> This attempts to clean up the way various compatibility
>> functions are defined and used.
> ...
>> --- a/compat/mmap.c
>> +++ b/compat/mmap.c
>> @@ -2,7 +2,7 @@
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <errno.h>
>> -#include "../cache.h"
>> +#include "../git-compat-util.h"
>
> I still think that compat functions should stand alone.
> Especially if it does not costs us much (or even less than that).
Sorry, you lost me. What do you mean by "standing alone"?
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Alex Riesen @ 2005-12-05 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe3vb8fh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 21:22:42 +0100:
> This attempts to clean up the way various compatibility
> functions are defined and used.
...
> --- a/compat/mmap.c
> +++ b/compat/mmap.c
> @@ -2,7 +2,7 @@
> #include <stdlib.h>
> #include <unistd.h>
> #include <errno.h>
> -#include "../cache.h"
> +#include "../git-compat-util.h"
I still think that compat functions should stand alone.
Especially if it does not costs us much (or even less than that).
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Junio C Hamano @ 2005-12-05 21:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051205213612.GA4443@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Dec 05, 2005 18:40:21 +0100:
>> > Why does it always happen...
>> Because you touched you did not absolutely have to ;-).
>
> well, git$(X) didn't link...
I meant your change to the "if ()" expression in gitfakemmap().
Does the change have anything to do with git$X linkage? I think
not.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-12-05 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052202300.12016@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, reading the code I am not satisfied. If there is no template for
> the config file, it does not test the filemode at all.
I have a feeling that you have not tried the code you are
arguing against.
It always creates the config file because it needs to record the
repository format version (among other things), so the config
file exists even if you do not have templates. Even if you do
not have a valid template directory that is supposed to work,
but obviously you have not tried it ;-).
Now, it is arguable that the current format version being 0, and
not having the format version is equivalent to having 0 as the
format version, it is not necessary to create an empty
configuration file at this moment, but by making sure we record
the format version the tool that created the repository supports
now in the version 0, we do not have to risk forgetting to add
that logic later when we _do_ need to write something non-zero.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Alex Riesen @ 2005-12-05 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vk6ejb72r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 21:51:56 +0100:
> >> This attempts to clean up the way various compatibility
> >> functions are defined and used.
> >
> > You sure you want that before 1.0?
>
> I think this is mostly an obvious clean-up, but I do not have
> enough test environments, so ...
I will do cygwin. Tomorrow, that is.
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Alex Riesen @ 2005-12-05 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyp7cuii.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Mon, Dec 05, 2005 18:40:21 +0100:
> > Why does it always happen...
> Because you touched you did not absolutely have to ;-).
well, git$(X) didn't link...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Jon Loeliger @ 2005-12-05 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, Git List
In-Reply-To: <7vu0dnb8pm.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-12-05 at 14:16, Junio C Hamano wrote:
> This question is probably relevant only to you and people who
> want to build deb themselves until you package the updated
> upstream, but what is your (and others') preference on debian/
> directory in what _I_ ship?
I would like to see it remain and be current, please.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Johannes Schindelin @ 2005-12-05 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek4rb6vc.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 5 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, you should also remove the header which is generated in init-db.c
> > when it is determined that the file system does not respect the executable
> > flag.
>
> I suspect that code is not there anymore.
Oops. I missed that one (probably because it did not say anything about
the filemode test in the shortlog).
However, reading the code I am not satisfied. If there is no template for
the config file, it does not test the filemode at all.
In fact, it reverses my design: I did *not* touch an existing config file,
but only created one if none existed. And if the filemode was not set, I
threw the config file away.
Ciao,
Dscho
^ permalink raw reply
* Re: cvsexportcommit/cvsimport workflow
From: Martin Langhoff @ 2005-12-05 20:57 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Git Mailing List
In-Reply-To: <200511212043.57434.lan@ac-sw.com>
On 11/21/05, Alexander Litvinov <lan@ac-sw.com> wrote:
> Can ypu please explain how to use cvsimport with cvsexportcommit scripts ?
Your approach is good -- that's exactly how I use them too. I normally
use git-format-patch to review what patches I have 'pending' to be
pushed upstream. It's great because it knows your last common commit,
and it uses git-cherry to spot commits that are identical on both
sides.
We should perhaps create git-cvsexport, followning git-format-patch's
usage of git-cherry, and calling git-cvsexportcommit with them.
There's been talk about doing it -- I'll probably do it as soon as I
need it for a project. Feel free to have a go at it ;-)
> 7. Export git commits to cvs: What should be exported question become harder
> and harder. Possible I should use some tag and run:
> git-rev-list MY-TAG..master | xargs -n 1 git-cvsexportcommit -vX -cX (by the
> way, why just -v -c does not work ? I must add something to make options
> work)
Strange. The getopts line should look like:
getopts('hpvc');
(al least it does on my repo) which means that it doesn't expect
parameter _values_. Have you got the same line in the script? Perhaps
your getopts is broken or strange?
> This cycle is a bit of mess. I can write some scripts but I have no idea how
> this is supposed to work !
Well... you have the right idea... and yes it's a bit of a mess.
> The biggest problem - conflict. I should resove them twice, during merging
> origin branch to master and when exporting these changes to cvs. By the way,
> I still can't export merge commit :-)
That's exactly the issue. It's somewhat manual -- because you can't
really automate it 100%. CVS won't know what to do with a merge, so
every time you develop in paralell under git and then merge, you'll
have to fudge things somehow to trick cvs. There's an impedance
mismatch there.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-12-05 20:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052124400.4026@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, you should also remove the header which is generated in init-db.c
> when it is determined that the file system does not respect the executable
> flag.
I suspect that code is not there anymore.
^ permalink raw reply
* Re: [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-05 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512052135260.5944@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This attempts to clean up the way various compatibility
>> functions are defined and used.
>
> You sure you want that before 1.0?
I think this is mostly an obvious clean-up, but I do not have
enough test environments, so ...
^ permalink raw reply
* Re: Weirdness with port-update hook and local push
From: Johannes Schindelin @ 2005-12-05 20:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0512051530560.25300@iabervon.org>
Hi,
On Mon, 5 Dec 2005, Daniel Barkalow wrote:
> I have the following post-update hook:
>
> -----
> #!/bin/sh
>
> unset GIT_DIR
> cd /home/barkalow/auto-working/web
> if ! git pull /home/barkalow/git/web.git/
> then
> exit 1
> fi
> make
> -----
>
> >From that "git pull", I'm getting:
>
> /home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
>
> It works fine when pushing over ssh,
Maybe it runs as a different user? (Sorry if this sounds dumb, but that's
exactly the kind of solution I usually find after *days*.)
Hth,
Dscho
^ 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