* [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: [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
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Junio C Hamano @ 2006-12-09 21:35 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <457AB54B.8070107@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 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.
Hardcoding $(bin)/git-sh-setup is a non-starter; it breaks
GIT_EXEC_PATH convention to allow users to override it.
You would need to make sure the following:
- If you are moving git-sh-setup out of the way, I think you
would need to do the same for git-parse-remote while you are
at it. There might be other scriptlets whose sole purpose is
to be sourced via "." (I haven't checked recently).
- It should be arranged so that "make test" would test the
version from the source tree, even when you have an installed
version of git-sh-setup and friends elsewhere on your PATH.
- People who build but do not install should be able to
continue using git from the build location with appropriate
environment settings (look for place that talks about PATH
and GIT_EXEC_PATH in INSTALL -- if you need something else,
you should document new requirements there).
I haven't looked closely, but I suspect your patch might have
broken the latter two.
Having said that, I still do not see the point of doing this.
Was there ever a case that you typed git-sh-setup on the command
line by mistake (in which case it might be a valid desire to
prevent the mistake from happening again)? Command complettion
might offer git-sh-setup when you say "git-<TAB>", which might
irritate you --- but these days you can use Shawn's completion
and say "git <TAB>" or "git somecommand<TAB>", which is way
nicer, and makes it not really an issue either.
In other words, I do not know what real problem you are trying
to solve.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: R. Steve McKown @ 2006-12-09 21:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612021114270.3476@woody.osdl.org>
On Saturday 02 December 2006 12:41 pm, Linus Torvalds wrote:
> In other words, I _suspect_ that that is really what module users are all
> about. They want the ability to specify an arbitrary collection of these
> atomic snapshots (for releases etc), and just want a way to copy and move
> those things around, and are less interested in making everything else
> very seamless (because most people are happy to do the actual
> _development_ entirely within the submodules, so the "development" part
> is actually not that important for the supermodule, the supermodule is
> mostly for aggregation and snapshots, and tying different versions of
> different submodules together).
>
> So that's where I come from. And maybe I'm totally wrong. I'd like to hear
> what people who actually _use_ submodules think.
Here's some thoughts on subprojects from my company's perspective. I
apologize for the long message.
Abstract: We use submodules heavily in CVS and SVN. I like what I've read
from Linus about the "thin veneer" approach of integrating subprojects. It
seems conceptually to provide the support we desire. For us, it's important
that the mandated linkage between a master project and a subproject is
minimal to maximize our flexibility in building our processes.
We develop and maintain a lot of embedded applications. Both for higher level
systems (ex: 32MB RAM/32MB storage) running the Linux kernel and a customized
set of libs/app support code and more deeply embedded environments (ex: 8KB
of RAM and 32KB of storage). Even though these two cases are very different
in many repects, the version management issues are the same.
- We (mostly) track everything needed to build historical versions of code
with 100% fidelity. This includes all of the tools used to compile, build,
test, deploy, debug, etc. the actual build results themselves. I initially
looked at Vesta several years ago. I love their conceptual approach to this
problem (integrated build system that caches mid-level build results within
the repository itself), but it's too unwieldy, very hard to set up (lots of
up-front effort), and lacks many useful features.
- Most of our "applications" are a relatively small amount of app-specific
code with references to several/many shared modules. Shared modules can
contain support tools, like build/test/debug/deploy support for a given
embedded platform, in-house developed shared app code, or shared code
developed by third parties.
- We use CVS to manage our larger system development projects. The repo is
about 2GB and has several dozen application-code submodules. We use the
"third party sources" approach to tracking submodules as outlined in Ch.13 of
the CVS manual. Additionally, we manage our "buildox" (similar to buildroot
in concept) in another CVS repo. All prior interesting versions of the
buildroot can be built from source (toolchains, everything), if necessary.
Applications contain metadata (a file...) in the repo so the app-level build
system can ensure it is being ran under the correct version of buildbox;
clunky but serviceable. CVS is a nightmare because of its poor
branch/tagging facilities, and many of the things we *ought* to be doing with
revision control we don't because of the complexity.
- We use SVN to manage our deeply embedded system projects. The repo is about
250MB in size. Applications use the svn:externals property to reference
needed modules. We aren't using a buildbox in this environment yet (bad!).
SVN's simple branching and svn:externals are a giant leap forward in
comparison to CVS's capabilities.
Below are some common use case scenarios that are to varying degrees unweildy
in CVS and/or SVN. Many of these involving non-trivial branching and merging
operations are nearly impractical in CVS, and the lack of merge tracking (to
support repeated safe merging from one branch to another) makes some of these
a bit tricky in SVN too. Of course neither repo supports
disconnected/distributed operation, which would make a number of activities
that much simpler as well.
- Round trip module management. A specific app requires a change to a shared
module, so it makes a local branch to develop the change. The "diff" is
presented to the maintainer (who may be inhouse). The next interesting
maintainer version of the module gets imported into our repo (if in house,
it's already there), where the app can reference it. This merge process may
leave changes not yet implemented (or never to be implemented) by the module
maintainer in the local branch used by the apps. Other apps are unaffected,
as they are linking to a prior version in the local branch.
- Pragmatic development. It's typical that in developing an application, a
developer will need to simultaneously make changes to one or more submodules.
If more than trivial, he/she should branch the submodules and continually
tracking the HEAD of those branches in the relevant app. This is so complex
and fraught with problems in CVS that it doesn't get done, and developers
house too much change over time in their working directories. With SVN and
svn:externals, the process is workable. It is nice that an svn:external can
point to (the HEAD of) a branch when making changes.
- An application implements a new feature internally (say support for a new
digital chipset in the embedded world) which later needs to be "promoted" to
a subproject for use by others. Pretty easy in SVN. A challenge in CVS;
it's really not possible to "convert" app code into a "third party source"
and retain an historical link.
- Updating build tools. In concept no different than updating a shared code
module. In practice, due to the buildbox strategy, it's a bit convoluted. I
don't expect this to get much smoother. Getting Vesta-like features, where
integrated build suport can cache lower-level build results in a version-safe
manner (like the binary code built when the cross toolchain was built) would
be killer, but that's surely OT for the submodules discussion.
Thanks,
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Alex Riesen @ 2006-12-09 21:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550612090951l43a83a00o7ea2e244ca562c77@mail.gmail.com>
Marco Costalba, Sat, Dec 09, 2006 18:51:57 +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).
Why do you need to save it in temporary file at all? Why don't you
read the output like gitk does? You can take a look at popen(3). It's
known to be portable among operating systems and libc's. Or, BTW, why
don't you just read qprocess.h, use processIdentifier()/pid(),
read*()-methods and the like? (though, looking at the QProcess in
^ permalink raw reply
* Re: [PATCH] shortlog: fix segfault on empty authorname
From: Nicolas Pitre @ 2006-12-09 21:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20061209040421.GA29113@coredump.intra.peff.net>
On Fri, 8 Dec 2006, Jeff King wrote:
> The old code looked backwards from the email address to parse the name,
> allowing an arbitrary number of spaces between the two. However, in the case
> of no name, we looked back too far to the 'author' (or 'Author:') header.
> Instead, remove at most one space between name and address.
>
> The bug was triggered by commit febf7ea4bed from linux-2.6.
>
> Signed-off-by: Jeff King <peff@peff.net>
Yep, that fixes the problem.
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Junio C Hamano @ 2006-12-09 21:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0612091517010.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> +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,...IMHO the merge
> example included further down should be sufficient information wrt
> committing a merge.
You are right --- removed.
>> -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)?
True, although the description of <files>... need to be
clarified if we do this.
>> +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.
Credit owed to JBF.
> I'd add (with links):
>
> SEE ALSO
> --------
> git-add, git-rm, git-mv, git-merge, git-commit-tree
Done.
Attached is an incremental patch on top of what you commented
on.
-- >8 --
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 8fe42cb..20a2cb3 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -34,12 +34,6 @@ methods:
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.
-
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
@@ -119,19 +113,15 @@ but can be used to amend a merge commit.
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 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.
-
\--::
Do not interpret any more arguments as options.
<file>...::
- Files to be committed. The meaning of these is
- different between `--include` and `--only`. Without
- either, it defaults `--only` semantics.
+ When files are given on the command line, the command
+ commits the contents of the named files, without
+ recording the changes already staged. The contents of
+ these files are also staged for the next commit on top
+ of what have been staged before.
EXAMPLES
@@ -240,6 +230,15 @@ This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
+
+SEE ALSO
+--------
+gitlink:git-add[1],
+gitlink:git-rm[1],
+gitlink:git-mv[1],
+gitlink:git-merge[1],
+gitlink:git-commit-tree[1]
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
^ permalink raw reply related
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Jakub Narebski @ 2006-12-09 22:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsas91e5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>>> -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)?
>
> True, although the description of <files>... need to be
> clarified if we do this.
I'm a bit uncomfortable about removing documentation to existing
(if no-op) option. I'd rather it stay.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Linus Torvalds @ 2006-12-09 22:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elfbq4$tka$1@sea.gmane.org>
On Sat, 9 Dec 2006, Jakub Narebski wrote:
>
> I'm a bit uncomfortable about removing documentation to existing
> (if no-op) option. I'd rather it stay.
How about mentioning it at the very end, under a "HYSTERICAL RAISINS"
header. That way it's documented, and people still know to ignore it.
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Jakub Narebski @ 2006-12-09 22:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612091418410.12895@woody.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 9 Dec 2006, Jakub Narebski wrote:
>>
>> I'm a bit uncomfortable about removing documentation to existing
>> (if no-op) option. I'd rather it stay.
>
> How about mentioning it at the very end, under a "HYSTERICAL RAISINS"
> header. That way it's documented, and people still know to ignore it.
"HISTORICAL NOTES". Yes, that is good idea.
Although for git-commit the option --only helps to explain what
"git commit <path>..." does. So perhaps it should stay where it was.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Nicolas Pitre @ 2006-12-09 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsas91e5.fsf@assigned-by-dhcp.cox.net>
On Sat, 9 Dec 2006, Junio C Hamano wrote:
> Attached is an incremental patch on top of what you commented
> on.
>
[...]
> <file>...::
> - Files to be committed. The meaning of these is
> - different between `--include` and `--only`. Without
> - either, it defaults `--only` semantics.
> + When files are given on the command line, the command
> + commits the contents of the named files, without
> + recording the changes already staged. The contents of
> + these files are also staged for the next commit on top
> + of what have been staged before.
Might something like "When -i is provided however..." be missing in the
above? Otherwise it is rather confusing.
Besides that I'm really happy with the result.
^ permalink raw reply
* Re: Easy shell question: how to make a script killing all his childs when killed?
From: Marco Costalba @ 2006-12-09 23:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20061209213937.GB12373@steel.home>
On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:
>
> Why do you need to save it in temporary file at all? Why don't you
> read the output like gitk does? You can take a look at popen(3). It's
> known to be portable among operating systems and libc's. Or, BTW, why
> don't you just read qprocess.h, use processIdentifier()/pid(),
> read*()-methods and the like? (though, looking at the QProcess in
> qt3, I wouldn't really blame you)
>
Well, I _used_ QProcess interface until last week. It's socket based
and it's quite fast (much more then gitk BTW), but due to some
internal buffering not so fast as reading from a file (in my last post
regarding git-rev-list access there are some performance numbers to
document this). It seems that socket/pipe based IPC is not as fast as
file write/read. Of course we are talking of OS cached files, no disk
access must be involved to keep the speed.
Probably someone more versed in IPC and OS internals could comment on
this, I just base my arguments on experimental testing of various IPC
systems without going deep in the reasons why the number are like
this, also because I don't have the necessary knowledge.
But the fact is that with temporary (in memory) data exchange file the
load time has been reduced by 40% against socket based QProcess
interface.
Regarding gitk we are at least one order of magnitude faster both with
QProcess and, more, with temporary files, so it's not a useful
reference in this case.
Marco
P.S: I didn't experiment with popen(). Thanks for the hint, I will
^ permalink raw reply
* Re: [PATCH] shortlog: fix segfault on empty authorname
From: Johannes Schindelin @ 2006-12-09 23:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <20061209040421.GA29113@coredump.intra.peff.net>
Hi,
On Fri, 8 Dec 2006, Jeff King wrote:
> Instead, remove at most one space between name and address.
Why? We can fix it properly: Instead of
> - while (isspace(bob[-1]))
> + if (isspace(bob[-1]))
do something like
while (bob - 1 != buffer + 7 &&
isspace(bob[-1]))
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Robin Rosenberg @ 2006-12-09 23:29 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 14078 bytes --]
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This patch uses git-apply to do the patching which simplifies the code a lot.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much tested.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
This is a cleaned up version of a previously submitted patch with same name.
I'm using non-ascii characters in the
git-cvsexportcommit.perl | 166 +++++++++++++---------------------------
t/t9200-git-cvsexportcommit.sh | 108 +++++++++++++++++++-------
2 files changed, 133 insertions(+), 141 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index c9d1d88..f1a9c1b 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -2,9 +2,8 @@ #!/usr/bin/perl -w
# Known limitations:
# - does not propagate permissions
-# - tells "ready for commit" even when things could not be completed
-# (not sure this is true anymore, more testing is needed)
-# - does not handle whitespace in pathnames at all.
+# - error handling has not been extensively tested
+#
use strict;
use Getopt::Std;
@@ -116,16 +115,13 @@ if ($opt_a) {
close MSG;
my (@afiles, @dfiles, @mfiles, @dirs);
-my %amodes;
-my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
-#print @files;
+my $files = safe_pipe_capture_blob('git-diff-tree', '-z', '-r', $parent, $commit);
$? && die "Error in git-diff-tree";
-foreach my $f (@files) {
- chomp $f;
- my @fields = split(m!\s+!, $f);
+while ($files =~ m/(.*?\000.*?\000)/g) {
+ my $f=$1;
+ my @fields = ( $f =~ m/^(\S+) (\S+) (\S+) (\S+) (\S+)\000(.*)\000/ );
if ($fields[4] eq 'A') {
my $path = $fields[5];
- $amodes{$path} = $fields[1];
push @afiles, $path;
# add any needed parent directories
$path = dirname $path;
@@ -141,20 +137,27 @@ foreach my $f (@files) {
push @dfiles, $fields[5];
}
}
-my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
-@binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
-map { chomp } @binfiles;
-@abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
-@dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
-@mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
-push @bfiles, @abfiles;
-push @bfiles, @dbfiles;
-push @bfiles, @mbfiles;
-push @mfiles, @mbfiles;
+my (@diff,@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
+@diff = safe_pipe_capture('git-diff-tree','--binary','-p',$parent,$commit);
+# the --binary format is harder to grok for names of binary files so we execute a new diff
+# if it looks like binary files exists to find out
+if (grep /^GIT binary patch$/, @diff) {
+ @binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
+ map { chomp } @binfiles;
+ @abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
+ @dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
+ @mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
+ push @abfiles, grep s/^Binary files \/dev\/null and "b\/(.*)" differ$/$1/, @binfiles;
+ push @dbfiles, grep s/^Binary files "a\/(.*)" and \/dev\/null differ$/$1/, @binfiles;
+ push @mbfiles, grep s/^Binary files "a\/(.*)" and \"b\/(.*)\" differ$/$1/, @binfiles;
+ push @bfiles, @abfiles;
+ push @bfiles, @dbfiles;
+ push @bfiles, @mbfiles;
+ map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg } @bfiles;
+}
$opt_v && print "The commit affects:\n ";
$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
-undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
@@ -197,87 +200,32 @@ if ($dirty) {
}
}
-###
-### NOTE: if you are planning to die() past this point
-### you MUST call cleanupcvs(@files) before die()
-###
-
-
-print "Creating new directories\n";
-foreach my $d (@dirs) {
- unless (mkdir $d) {
- warn "Could not mkdir $d: $!";
- $dirty = 1;
- }
- `cvs add $d`;
- if ($?) {
- $dirty = 1;
- warn "Failed to cvs add directory $d -- you may need to do it manually";
- }
-}
-
-print "'Patching' binary files\n";
-
-foreach my $f (@bfiles) {
- # check that the file in cvs matches the "old" file
- # extract the file to $tmpdir and compare with cmp
- if (not(grep { $_ eq $f } @afiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- `git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-s', $f, "$tmpdir/blob")) {
- warn "Binary file $f in CVS does not match parent.\n";
- if (not $opt_f) {
- $dirty = 1;
- next;
- }
- }
- }
- if (not(grep { $_ eq $f } @dfiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- # replace with the new file
- `git-cat-file blob $blob > $f`;
- }
-
- # TODO: something smart with file modes
-
-}
-if ($dirty) {
- cleanupcvs(@files);
- die "Exiting: Binary files in CVS do not match parent";
-}
-
## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
-print "Patching non-binary files\n";
+print "Patching\n";
-if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
- print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
-}
+open APPLY, "|GIT_DIR= git-apply -C$fuzz" || die "cannot patch";
+(print APPLY @diff) || die "cannot patch";
+close APPLY || die "cannot patch";
+print "Patch applied successfully. Adding new files and directories to CVS\n";
my $dirtypatch = 0;
-if (($? >> 8) == 2) {
- cleanupcvs(@files);
- die "Exiting: Patch reported serious trouble -- you will have to apply this patch manually";
-} elsif (($? >> 8) == 1) { # some hunks failed to apply
- $dirtypatch = 1;
+foreach my $d (@dirs) {
+ if (system('cvs','add',$d)) {
+ $dirtypatch = 1;
+ warn "Failed to cvs add directory $d -- you may need to do it manually";
+ }
}
foreach my $f (@afiles) {
- set_new_file_permissions($f, $amodes{$f});
if (grep { $_ eq $f } @bfiles) {
system('cvs', 'add','-kb',$f);
} else {
system('cvs', 'add', $f);
}
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs add $f -- you may need to do it manually";
}
}
@@ -285,29 +233,29 @@ foreach my $f (@afiles) {
foreach my $f (@dfiles) {
system('cvs', 'rm', '-f', $f);
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs rm -f $f -- you may need to do it manually";
}
}
print "Commit to CVS\n";
-print "Patch: $title\n";
-my $commitfiles = join(' ', @afiles, @mfiles, @dfiles);
-my $cmd = "cvs commit -F .msg $commitfiles";
+print "Patch title (first comment line): $title\n";
+my @commitfiles = map { unless (m/\s/) { '\''.$_.'\''; } else { $_; }; } (@afiles, @mfiles, @dfiles);
+my $cmd = "cvs commit -F .msg @commitfiles";
if ($dirtypatch) {
print "NOTE: One or more hunks failed to apply cleanly.\n";
- print "Resolve the conflicts and then commit using:\n";
+ print "You'll need to apply the patch in .cvsexportcommit.diff manually\n";
+ print "using a patch program. After applying the patch and resolving the\n";
+ print "problems you may commit using:";
print "\n $cmd\n\n";
exit(1);
}
-
if ($opt_c) {
print "Autocommit\n $cmd\n";
print safe_pipe_capture('cvs', 'commit', '-F', '.msg', @afiles, @mfiles, @dfiles);
if ($?) {
- cleanupcvs(@files);
die "Exiting: The commit did not succeed";
}
print "Committed successfully to CVS\n";
@@ -321,17 +269,6 @@ END
exit(1);
}
-# ensure cvs is clean before we die
-sub cleanupcvs {
- my @files = @_;
- foreach my $f (@files) {
- system('cvs', '-q', 'update', '-C', $f);
- if ($?) {
- warn "Warning! Failed to cleanup state of $f\n";
- }
- }
-}
-
# An alternative to `command` that allows input to be passed as an array
# to work around shell problems with weird characters in arguments
# if the exec returns non-zero we die
@@ -346,12 +283,15 @@ sub safe_pipe_capture {
return wantarray ? @output : join('',@output);
}
-# For any file we want to add to cvs, we must first set its permissions
-# properly, *before* the "cvs add ..." command. Otherwise, it is impossible
-# to change the permission of the file in the CVS repository using only cvs
-# commands. This should be fixed in cvs-1.12.14.
-sub set_new_file_permissions {
- my ($file, $perm) = @_;
- chmod oct($perm), $file
- or die "failed to set permissions of \"$file\": $!\n";
+sub safe_pipe_capture_blob {
+ my $output;
+ if (my $pid = open my $child, '-|') {
+ local $/;
+ undef $/;
+ $output = (<$child>);
+ close $child or die join(' ',@_).": $! $?";
+ } else {
+ exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
+ }
+ return $output;
}
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index c102479..63eafc8 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -89,18 +89,17 @@ test_expect_success \
! git cvsexportcommit -c $id
)'
-# Should fail, but only on the git-cvsexportcommit stage
-test_expect_success \
- 'Fail to remove binary file more than one generation old' \
- 'git reset --hard HEAD^ &&
- cat F/newfile6.png >>D/newfile4.png &&
- git commit -a -m "generation 2 (again)" &&
- rm -f D/newfile4.png &&
- git commit -a -m "generation 3" &&
- id=$(git rev-list --max-count=1 HEAD) &&
- (cd "$CVSWORK" &&
- ! git cvsexportcommit -c $id
- )'
+#test_expect_success \
+# 'Fail to remove binary file more than one generation old' \
+# 'git reset --hard HEAD^ &&
+# cat F/newfile6.png >>D/newfile4.png &&
+# git commit -a -m "generation 2 (again)" &&
+# rm -f D/newfile4.png &&
+# git commit -a -m "generation 3" &&
+# id=$(git rev-list --max-count=1 HEAD) &&
+# (cd "$CVSWORK" &&
+# ! git cvsexportcommit -c $id
+# )'
# We reuse the state from two tests back here
@@ -108,7 +107,7 @@ # This test is here because a patch for
# fail with gnu patch, so cvsexportcommit must handle that.
test_expect_success \
'Remove only binary files' \
- 'git reset --hard HEAD^^^ &&
+ 'git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
@@ -142,20 +141,73 @@ test_expect_success \
diff F/newfile6.png ../F/newfile6.png
)'
-test_expect_success 'Retain execute bit' '
- mkdir G &&
- echo executeon >G/on &&
- chmod +x G/on &&
- echo executeoff >G/off &&
- git add G/on &&
- git add G/off &&
- git commit -a -m "Execute test" &&
- (
- cd "$CVSWORK" &&
- git-cvsexportcommit -c HEAD
- test -x G/on &&
- ! test -x G/off
- )
-'
+test_expect_success \
+ 'New file with spaces in file name' \
+ 'mkdir "G g" &&
+ echo ok then >"G g/with spaces.txt" &&
+ git add "G g/with spaces.txt" && \
+ cp ../test9200a.png "G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "With spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id &&
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.1/-kb with spaces.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Update file with spaces in file name' \
+ 'echo Ok then >>"G g/with spaces.txt" &&
+ cat ../test9200a.png >>"G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "Update with spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
+ )'
+
+# This test contains ISO-8859-1 characters
+test_expect_success \
+ 'File with non-ascii file name' \
+ 'mkdir Å &&
+ echo Foo >Å/gårdetsågårdet.txt &&
+ git add Å/gårdetsågårdet.txt &&
+ cp ../test9200a.png Å/gårdetsågårdet.png &&
+ git add Å/gårdetsågårdet.png &&
+ git commit -a -m "Går det så går det" && \
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -v -c $id &&
+ test "$(echo $(sort Å/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Mismatching patch should fail' \
+ 'date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update one" &&
+ date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update two" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git-cvsexportcommit -c $id
+ )'
+
+test_expect_success \
+ 'Retain execute bit' \
+ 'mkdir G &&
+ echo executeon >G/on &&
+ chmod +x G/on &&
+ echo executeoff >G/off &&
+ git add G/on &&
+ git add G/off &&
+ git commit -a -m "Execute test" &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c HEAD
+ test -x G/on &&
+ ! test -x G/off
+ )'
^ permalink raw reply related
* Re: builtin git-shortlog still broken
From: Johannes Schindelin @ 2006-12-09 23:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612082205240.2630@xanadu.home>
Hi,
On Fri, 8 Dec 2006, Nicolas Pitre wrote:
> On the Linux kernel repository, doing "git shortlog v2.6.18.." works
> fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
> works fine. But "git shortlog v2.6.15.." dies with a segmentation
> fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
> crash while "git log v2.6.16.. | git shortlog" works fine.
>
> The old perl version doesn't have any such issue with those test cases,
> not even with the whole kernel history.
Yeah, sorry. I assumed that there are enough sanity checks for the author
format, but evidently that is/was not the case here.
Ciao,
Dscho
^ 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 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wn8ah2k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> 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.
>
> Hardcoding $(bin)/git-sh-setup is a non-starter; it breaks
> GIT_EXEC_PATH convention to allow users to override it.
> In other words, I do not know what real problem you are trying
> to solve.
The real problem is that git is nonstandard to wrap around:
scripts like git-sh-setup need special attention, because they don't work
with
exec /some/where/else/git-sh-setup "$@"
I admit is a small problem, but IMO that's not an argument not to solve it.
--
^ permalink raw reply
* [PATCH 1/3] diff_tree_sha1(): avoid rereading trees if possible
From: Johannes Schindelin @ 2006-12-09 23:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061207101707.GA19139@spearce.org>
If the tree has already been read, no need to read it into memory
again.
This also helps when this function is called on temporary trees;
these no longer have to be written to disk.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
tree-diff.c | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 9d80dfb..54a6b44 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -195,23 +195,34 @@ int diff_tree(struct tree_desc *t1, struct tree_desc *t2, const char *base, stru
return 0;
}
+static int get_tree_desc_from_sha1(const unsigned char *sha1,
+ struct tree_desc *t)
+{
+ struct object *o;
+
+ o = lookup_object(sha1);
+ if (o && o->type == OBJ_TREE && o->parsed) {
+ struct tree *tree = (struct tree *)o;
+ t->size = tree->size;
+ t->buf = xmalloc(t->size);
+ memcpy(t->buf, tree->buffer, t->size);
+ } else {
+ t->buf = read_object_with_reference(sha1,
+ tree_type, &t->size, NULL);
+ if (!t->buf)
+ die("unable to read source tree (%s)",
+ sha1_to_hex(sha1));
+ }
+}
+
int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const char *base, struct diff_options *opt)
{
- void *tree1, *tree2;
struct tree_desc t1, t2;
int retval;
- tree1 = read_object_with_reference(old, tree_type, &t1.size, NULL);
- if (!tree1)
- die("unable to read source tree (%s)", sha1_to_hex(old));
- tree2 = read_object_with_reference(new, tree_type, &t2.size, NULL);
- if (!tree2)
- die("unable to read destination tree (%s)", sha1_to_hex(new));
- t1.buf = tree1;
- t2.buf = tree2;
+ get_tree_desc_from_sha1(old, &t1);
+ get_tree_desc_from_sha1(new, &t2);
retval = diff_tree(&t1, &t2, base, opt);
- free(tree1);
- free(tree2);
return retval;
}
--
1.4.4.2.g0f32-dirty
^ permalink raw reply related
* [PATCH 2/3] merge-recursive: make empty tree a known object
From: Johannes Schindelin @ 2006-12-09 23:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061207101707.GA19139@spearce.org>
To use it in diff_tree_sha1(), a tree has to be hashed in the
global object collection. This actually moves the empty tree (if
it is needed) into the global object hash.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
merge-recursive.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 6e13b8e..280f23c 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1220,9 +1220,10 @@ static int merge(struct commit *h1,
/* if there is no common ancestor, make an empty tree */
struct tree *tree = xcalloc(1, sizeof(struct tree));
+ hash_sha1_file(NULL, 0, tree_type, tree->object.sha1);
+ created_object(tree->object.sha1, &tree->object);
tree->object.parsed = 1;
tree->object.type = OBJ_TREE;
- hash_sha1_file(NULL, 0, tree_type, tree->object.sha1);
merged_common_ancestors = make_virtual_commit(tree, "ancestor");
}
--
1.4.4.2.g0f32-dirty
^ permalink raw reply related
* [PATCH 3/3] add test case for recursive merge
From: Johannes Schindelin @ 2006-12-09 23:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061207101707.GA19139@spearce.org>
This test case is based on the bug report by Shawn Pearce.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t6024-recursive-merge.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
new file mode 100644
index 0000000..5f821fb
--- /dev/null
+++ b/t/t6024-recursive-merge.sh
@@ -0,0 +1,68 @@
+#!/bin/sh
+
+test_description='Test merge without common ancestors'
+. ./test-lib.sh
+
+# This scenario is based on a real-world repository of Shawn Pearce.
+
+# 1 - A - D - F
+# \ X /
+# B X
+# X \
+# 2 - C - E - G
+
+echo 1 > a1
+git add a1
+git commit -m 1 a1
+
+git checkout -b A master
+echo A > a1
+git commit -m A a1
+
+git checkout -b B master
+echo B > a1
+git commit -m B a1
+
+git checkout -b D A
+git-rev-parse B > .git/MERGE_HEAD
+echo D > a1
+git update-index a1
+git commit -m D
+
+git symbolic-ref HEAD refs/heads/other
+echo 2 > a1
+git commit -m 2 a1
+
+git checkout -b C
+echo C > a1
+git commit -m C a1
+
+git checkout -b E C
+git-rev-parse B > .git/MERGE_HEAD
+echo E > a1
+git update-index a1
+git commit -m E
+
+git checkout -b G E
+git-rev-parse A > .git/MERGE_HEAD
+echo G > a1
+git update-index a1
+git commit -m G
+
+git checkout -b F D
+git-rev-parse C > .git/MERGE_HEAD
+echo F > a1
+git update-index a1
+git commit -m F
+
+test_expect_failure "combined merge conflicts" "git merge -m final G"
+
+git ls-files --stage > out
+cat > expect << EOF
+100644 cf84443e49e1b366fac938711ddf4be2d4d1d9e9 2 a1
+100644 fd7923529855d0b274795ae3349c5e0438333979 3 a1
+EOF
+
+test_expect_success "virtual trees were processed" "diff -u expect out"
+
+test_done
--
1.4.4.2.g0f32-dirty
^ permalink raw reply related
* Re: Documentation/git-commit.txt
From: Horst H. von Brand @ 2006-12-10 0:11 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200612082256.45456.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
[...]
> How about the following wording here
>
> Instead of staging the content of each file immediately after changing
> it, you can wait until you have completed all the changes you want to
> make and then use the `-a` option to tell `git commit` to look for all
> changes to the content it is tracking and commit it automatically. That
^^^^^^^
files
(or "files whose contents")
> is, this example ...
[Yes, git tracks the contents of files, but it also has a list of files
whose contents it is tracking]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: [PATCH 3/3] add test case for recursive merge
From: Johannes Schindelin @ 2006-12-10 0:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612100056090.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
this test succeeds consistently on the machine where I tested it
originally, but fails on another of my machines, but only when run without
"-v". Very annoying. I will not have time to investigate until Monday,
though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Josef Weidendorfer @ 2006-12-10 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, J. Bruce Fields
In-Reply-To: <7vd56tei20.fsf_-_@assigned-by-dhcp.cox.net>
Very nice.
On Saturday 09 December 2006 06:48, Junio C Hamano wrote:
> 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
What about: "... must be explicitly identified (that is,
must be "staged") ..."
This way, it will be clear for the reader that "to explicitly identify" is the
same thing as "to stage", which is used quite often later.
> +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");
Regarding this note: Of course unmodified files do not have to be added ;-)
What about: "(Note: changes in files already known to git, and even new
changes done after a previous `git add` for a given file, still must
be staged again)"
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Josef Weidendorfer @ 2006-12-10 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Seth Falcon, git
In-Reply-To: <7vfybpg9yx.fsf@assigned-by-dhcp.cox.net>
On Saturday 09 December 2006 01:59, Junio C Hamano wrote:
> Maybe the "git add --interactive" would give you a transcript
> like this:
>
> $ git add --interactive '*.c' '*.h'
> showing list of modified files...
> 1) bozbar.c 2) filfre.c 3) frotz.h 4) nitfol.c 5) rezrov.h
> 6) xyzzy.c 7) yomin.h 8) z.c
> choice> 2 3 5 6 7
> showing list of modified files...
> 1) bozbar.c 2* filfre.c 3* frotz.h 4) nitfol.c 5* rezrov.h
> 6* xyzzy.c 7* yomin.h 8) z.c
> choice> 4+
> showing "git diff -- nitfol.c"...
> diff --git a/nitfol.c b/nitfol.c
> @@ -22,x +22,y @@
> {
> - int i;
> + long i;
> + i = 314;
>
> stage this hunk [Yes/No/All/Done]? y
Wow.
Something like this really would be good.
And please a way to "unstage" accidently added files/hunks, too ;-)
I even miss such a feature in stgit ("specify hunks to break up one
patch into two").
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Junio C Hamano @ 2006-12-10 0:50 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <457B4981.2030408@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> The real problem is that git is nonstandard to wrap around:
> scripts like git-sh-setup need special attention, because they don't work
> with
>
> exec /some/where/else/git-sh-setup "$@"
Of course. Who would want to wrap git-sh-setup that way?
The only thing you would need to wrap around is "git" itself,
isn't it?
^ permalink raw reply
* Re: [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Nicolas Pitre @ 2006-12-10 0:51 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <200612100130.48812.Josef.Weidendorfer@gmx.de>
On Sun, 10 Dec 2006, Josef Weidendorfer wrote:
> Very nice.
>
> On Saturday 09 December 2006 06:48, Junio C Hamano wrote:
> > 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
>
> What about: "... must be explicitly identified (that is,
> must be "staged") ..."
>
> This way, it will be clear for the reader that "to explicitly identify" is the
> same thing as "to stage", which is used quite often later.
Hmmm, maybe, maybe not. Although I don't have particular problem with
"staging area", I'm still unconvinced about the verb "stage".
> > +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");
>
> Regarding this note: Of course unmodified files do not have to be added ;-)
>
> What about: "(Note: changes in files already known to git, and even new
> changes done after a previous `git add` for a given file, still must
> be staged again)"
This is getting too long for what it is worth in this case IMHO.
^ 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