* Re: rebase -i: Should --continue auto-amend after failed exec?
From: Matthieu Moy @ 2011-08-24 13:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git@vger.kernel.org List
In-Reply-To: <4E40511B.7090206@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> If after a failed "exec" instruction there are staged changes, then currently rebase
> --continue fails with:
>
> .../git-rebase--interactive: line 774: .../.git/rebase-merge/author-script: No such file or directory
That's obviously bad, there should at least be an accurate error
message.
> But shouldn't this amend the HEAD commit? The documentation is not clear
> (from git-rebase.txt):
>
> The interactive rebase will stop when a command fails (i.e. exits with
> non-0 status) to give you an opportunity to fix the problem. You can
> continue with `git rebase --continue`.
>
> This may be interpreted to work like "edit", and IMO would be a very useful
> modus operandi.
I'm not sure. What happens in "edit" is that when reaching the "edit"
line, git-rebase--interactive.sh calls die_with_patch, which writes
author information in .git/rebase-merge/author-script, which really
means "I've stopped on this commit, this is the one that we should
implicitely amend with --continue".
The case of "exec" is a bit different: you don't stop "on a commit", but
after doing something else. You can hardly guess whether the staged
changes are meant to amend the existing commit, or to make a new one.
Actually, that could even be
pick deadbeef Existing commit
exec foo > bar.txt; git add bar.txt; git commit -m "added during rebase"
exec false
pick c00ffee Another commit
then auto-amending may be really confusing: should it amend the HEAD
commit that you've just created (this would really go against the logic
of .git/rebase-merge/author-script) or the last picked commit (which you
can't really do since it's not HEAD)?
I think it's best to abort, with an accurate error message pointing the
user to both solutions (commit --amend && rebase --continue or commit &&
rebase --continue). I'll try a patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Documentation: Grammar correction, wording fixes and cleanup
From: Ben Walton @ 2011-08-24 12:54 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <1314185245.13674.7.camel@drew-northup.unet.maine.edu>
Excerpts from Drew Northup's message of Wed Aug 24 07:27:25 -0400 2011:
> Thanks Ben.
No problem. Your fix was simpler and better. I missed the forest for
the trees on that change.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Problem with S_IFGITLINK
From: Adam Kłobukowski @ 2011-08-24 12:49 UTC (permalink / raw)
To: git
Hello
I'm trying to compile git on some very exotic u*ix flavor (FreeMiNT
anyone? :)) and I encountered problem with S_IFGITLINK.
Unfortunately, on my system S_IFGITLINK = S_IFLNK, and it breaks build
in entry.c write_entry.
Should I report a bug? (where?, I could not find any reference to
bugtracker on git pages)
Can I fix it somehow? Can I change value of S_IFGITLINK to something else?
AdamK
^ permalink raw reply
* Re: [PATCH 4/4] Add documentation for ref namespaces
From: Ævar Arnfjörð Bjarmason @ 2011-08-24 12:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jamey Sharp, Shawn O. Pearce, Johannes Schindelin, Jeff King,
Jakub Narebski, git, Josh Triplett
In-Reply-To: <7vfwksrqp1.fsf@alter.siamese.dyndns.org>
On Tue, Aug 23, 2011 at 19:19, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Tue, Jun 7, 2011 at 20:21, Jamey Sharp <jamey@minilop.net> wrote:
>>
>>> Document the namespace mechanism in a new gitnamespaces(7) page.
>>> Reference it from receive-pack and upload-pack.
>>
>> This breaks the build on older asciidoc versions, the fix is to do
>> what I did in f5008f56d5aba06598e1c6272f4f55b4ee4bb016.
>
> Thanks for a sharp-eye, even though I would have appreciated it even more
> if you spotted it while the series was still in 'next'.
That should work. And I very rarely compile things on these old boxes
so I usually don't spot them until they hit master. Sorry.
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Be clearer about the symbolic ref nature of HEAD
From: Drew Northup @ 2011-08-24 11:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <f903e0bb1c14cb083c263deb165dc9495ab4c60e.1314179720.git.git@drmicha.warpmail.net>
On Wed, 2011-08-24 at 11:56 +0200, Michael J Gruber wrote:
> "git reset" updates the ref which HEAD points to (or HEAD itself, if
> detached), due to being a symbolic ref (unless detached). Therefore,
> "updating/resetting HEAD" is a possible source of confusion especially when
> compared with "git checkout", and the change in
> d537c74 (git-reset.txt: make modes description more consistent, 2010-09-15)
> did not quite help.
>
> Clean up after d537c74 (myself) and try to be even clearer about which
> ref is changed by "git reset". Avoid the term "symbolic ref", because who can
> tell *HEAD from HEAD from &HEAD?
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
Looks reasonable to me.
> Documentation/git-reset.txt | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> index b2832fc..96c964d 100644
> --- a/Documentation/git-reset.txt
> +++ b/Documentation/git-reset.txt
> @@ -15,7 +15,7 @@ SYNOPSIS
> DESCRIPTION
> -----------
> In the first and second form, copy entries from <commit> to the index.
> -In the third form, set the current branch head (HEAD) to <commit>, optionally
> +In the third form, set the current branch head (which HEAD points to) to <commit>, optionally
> modifying index and working tree to match. The <commit> defaults to HEAD
> in all forms.
>
> @@ -44,8 +44,9 @@ you can use it to selectively reset hunks. See the ``Interactive Mode''
> section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.
>
> 'git reset' [--<mode>] [<commit>]::
> - This form resets the current branch head to <commit> and
> - possibly updates the index (resetting it to the tree of <commit>) and
> + This form resets the current branch head (which HEAD points to) to <commit>;
> + if HEAD points to a commit (aka detached HEAD) then HEAD is reset to <commit>.
> + This form also possibly updates the index (resetting it to the tree of <commit>) and
> the working tree depending on <mode>, which
> must be one of the following:
> +
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH 6/6] Retain caches of submodule refs
From: Michael Haggerty @ 2011-08-24 11:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Drew Northup, Jakub Narebski
In-Reply-To: <7v4o1hgemp.fsf@alter.siamese.dyndns.org>
On 08/17/2011 12:45 AM, Junio C Hamano wrote:
> All the changes except for this one made sense to me, but I am not sure
> about this one. How often do we look into different submodule refs in the
> same process over and over again?
As I've mentioned, I am not very familiar with submodules and I don't
know what actions in submodules can be triggered from the top-level
project. Here is the only code path that I can find in the current git
code that causes submodule refs to be read at all:
setup_revisions() with opt->submodule is set,
which can only happen when called via merge_submodule(),
which is called from merge_file() in merge-recursive.c,
which is called by process_renames() and merge_content(),
which are both ultimately called from merge_trees().
I don't know how often this can happen during the lifetime of one process.
The cost of retaining the submodule ref caches is roughly 100 bytes per
reference of memory. Another side effect is that the submodule caches
never have to be cleaned up; this saves a list walk and one free() per
cached reference if the refs for more than one submodule are accessed.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Documentation: Grammar correction, wording fixes and cleanup
From: Drew Northup @ 2011-08-24 11:27 UTC (permalink / raw)
To: Ben Walton; +Cc: gitster, git
In-Reply-To: <1314145955-23444-1-git-send-email-bwalton@artsci.utoronto.ca>
On Tue, 2011-08-23 at 20:32 -0400, Ben Walton wrote:
> Correct a few grammar issues in gitrepository-layout.txt and also
> rewords a few sections for clarity.
>
> Remove references to using http-fetch without -a to create a broken
> repository.
>
> Mark a few areas of the repository structure as legacy.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
Thanks Ben.
Looks good to me. I haven't tried applying it yet (it might not apply to
my bowl of breakfast cereal so well, but then again I should not be
surprised).
> Documentation/gitrepository-layout.txt | 58 +++++++++++++++-----------------
> 1 files changed, 27 insertions(+), 31 deletions(-)
>
> diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
> index eb3d040..5c891f1 100644
> --- a/Documentation/gitrepository-layout.txt
> +++ b/Documentation/gitrepository-layout.txt
> @@ -23,32 +23,25 @@ objects::
> Object store associated with this repository. Usually
> an object store is self sufficient (i.e. all the objects
> that are referred to by an object found in it are also
> - found in it), but there are couple of ways to violate
> - it.
> + found in it), but there are a few ways to violate it.
> +
> -. You could populate the repository by running a commit walker
> -without `-a` option. Depending on which options are given, you
> -could have only commit objects without associated blobs and
> -trees this way, for example. A repository with this kind of
> -incomplete object store is not suitable to be published to the
> -outside world but sometimes useful for private repository.
> -. You also could have an incomplete but locally usable repository
> -by cloning shallowly. See linkgit:git-clone[1].
> -. You can be using `objects/info/alternates` mechanism, or
> -`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
> +. You could have an incomplete but locally usable repository
> +by creating a shallow clone. See linkgit:git-clone[1].
> +. You could be using the `objects/info/alternates` or
> +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
> objects from other object stores. A repository with this kind
> of incomplete object store is not suitable to be published for
> use with dumb transports but otherwise is OK as long as
> -`objects/info/alternates` points at the right object stores
> -it borrows from.
> +`objects/info/alternates` points at the object stores it
> +borrows from.
>
> objects/[0-9a-f][0-9a-f]::
> - Traditionally, each object is stored in its own file.
> - They are split into 256 subdirectories using the first
> - two letters from its object name to keep the number of
> - directory entries `objects` directory itself needs to
> - hold. Objects found here are often called 'unpacked'
> - (or 'loose') objects.
> + A newly created object is stored in its own file.
> + The objects are splayed over 256 subdirectories using
> + the first two characters of the sha1 object name to
> + keep the number of directory entries in `objects`
> + itself to a manageable number. Objects found
> + here are often called 'unpacked' (or 'loose') objects.
>
> objects/pack::
> Packs (files that store many object in compressed form,
> @@ -85,7 +78,7 @@ objects/info/http-alternates::
>
> refs::
> References are stored in subdirectories of this
> - directory. The 'git prune' command knows to keep
> + directory. The 'git prune' command knows to preserve
> objects reachable from refs found in this directory and
> its subdirectories.
>
> @@ -119,16 +112,17 @@ HEAD::
> +
> HEAD can also record a specific commit directly, instead of
> being a symref to point at the current branch. Such a state
> -is often called 'detached HEAD', and almost all commands work
> -identically as normal. See linkgit:git-checkout[1] for
> -details.
> +is often called 'detached HEAD.' See linkgit:git-checkout[1]
> +for details.
>
> branches::
> A slightly deprecated way to store shorthands to be used
> - to specify URL to 'git fetch', 'git pull' and 'git push'
> - commands is to store a file in `branches/<name>` and
> - give 'name' to these commands in place of 'repository'
> - argument.
> + to specify a URL to 'git fetch', 'git pull' and 'git push'.
> + A file can be stored as `branches/<name>` and then
> + 'name' can be given to these commands in place of
> + 'repository' argument. See the REMOTES section in
> + linkgit:git-fetch[1] for details. This mechanism is legacy
> + and not likely to be found in modern repositories.
>
> hooks::
> Hooks are customization scripts used by various git
> @@ -173,9 +167,11 @@ info/exclude::
> at it. See also: linkgit:gitignore[5].
>
> remotes::
> - Stores shorthands to be used to give URL and default
> - refnames to interact with remote repository to
> - 'git fetch', 'git pull' and 'git push' commands.
> + Stores shorthands for URL and default refnames for use
> + when interacting with remote repositories via 'git fetch',
> + 'git pull' and 'git push' commands. See the REMOTES section
> + in linkgit:git-fetch[1] for details. This mechanism is legacy
> + and not likely to be found in modern repositories.
>
> logs::
> Records of changes made to refs are stored in this
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import
From: Vitor Antunes @ 2011-08-24 10:46 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110823231034.GA11918@arf.padd.com>
On Wed, Aug 24, 2011 at 12:10 AM, Pete Wyckoff <pw@padd.com> wrote:
> Nice analysis. P4 can indeed be the bottleneck, even on near
> servers if there are lots of files. Diff-tree seems like the
> better choice to find the branch point. I don't understand fully
> why the way we are using fast-import causes these problems. Will
> look at that next.
I came up with some ideas during sleep:
1. When doing a "checkpoint" it would make sense to have some kind of
feedback loop to know when fast-import completes it. In fact, I've
just looked at fast-import man page and the "progress" command seems
to do exactly that! Myabe we should crease a specific function for
"checkpoint" that would call also "progress" instead of calling
os.sleep().
2. In order to avoid needing to use "--force" it would be nice to have
some form of "drop" command in fast-import that would allows us to
actively drop an older commit after calling "reset" (this could even
be an option of "reset"). This way fast-import would not find
dangling commits in the end of the import. Maybe there's already
some sort of command to achieve this in fast-import...? We could
probably ask to one of its maintainers.
--
Vitor Antunes
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Johannes Sixt @ 2011-08-24 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, pascal, git
In-Reply-To: <7vaab0rodu.fsf@alter.siamese.dyndns.org>
Am 23.08.2011 20:09, schrieb Junio C Hamano:
> Ramsay Jones<ramsay@ramsay1.demon.co.uk> writes:
>
>> Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
>> 05-08-2011) in pu needs an update to fix the commit message.
>
> Thanks for a reminder, Ramsay.
>
> Here is the exchange where fixing the commit log was mentioned.
>
> From: Pascal Obry<pascal@obry.net>
> Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
> To: Ramsay Jones<ramsay@ramsay1.demon.co.uk>
> Cc: git@vger.kernel.org
> Date: Sat, 13 Aug 2011 19:34:37 +0200
> Message-ID:<4E46B5AD.5050806@obry.net>
>
> Le 11/08/2011 22:35, Ramsay Jones a écrit :
> > ... could you please correct your commit message. Thanks!
>
> Done, thanks for your review.
>
>> Also, I didn't see any response to Johannes Sixt's query concerning
>> backslash in pathspec. (I personally don't want to go down that
>> route, but ...)
>
> Here is what J6t said in the message:
>
> From: Johannes Sixt<j6t@kdbg.org>
> Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
> Date: Tue, 09 Aug 2011 21:47:15 +0200
> Message-ID:<4E418EC3.4070904@kdbg.org>
>
> > Do you also want to support this:
> > $ git add src\file.c
> > i.e., backslash in pathspec? Then you need more than this:
> > > +#define has_dos_drive_prefix(path) (isalpha(*(path))&& (path)[1] == ':')
> > > +#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
> >
> > In particular, you have to enable backslash processing in
> > setup.c:prefix_filename(), but then you lose the ability to escape
> > special characters with the backslash.
>
> When "git add src\file.c" is given from the command line, what does our
> main() see in argv[2]? Do cmd.exe and bash give us the same thing? What if
> the command line is "git add 'src\*.c'"?
Our main() sees the string as given on the command line, i.e., with the
backslash.
> I vaguely recall that on Windows you only get a single parameter string
> from the program loader, and arguments are split in the invoked process,
> but that is so common that as far as our main() is concerned we can expect
> the example command line to give us argc=3 and argv={ "git", "add", "???",
> NULL }. What I do not recall is if there is some other magic such as
> expanding shell globs and swapping the direction of slashes in strings
> involved when this argument processing is done.
There is a linker option whether shell globs should be expanded or not
before they are passed to main(). If the option is enabled, the expansion
is different from the way mandated by POSIX.
There was a proposal recently (on the msysgit list?) that this option
should be disabled, and any expansion of pathspec (globs) should be done
entirely by git's own expansion rules, which includes automatic recursive
matching. As a result, git would behave differently on Windows and Unix,
but since it already does when the linker option is enabled, we argue that
git's rules are superior (and Windows's linker option is inferior), we
better should go the proposed new route.
> You probably _could_ do '\\' -> '/' inside prefix_filename() and
> get_pathspec(), but as J6t mentioned, we _do_ handle backslash as a
> quoting character, and this is _not_ going to change.
... not going to change on platforms where this already works. It does not
work on Windows.
> So even if we were to go that route, the user would need to make git see
> "src\\file.c" or "src\\*.c" in order to make it turn into "src/file.c" and
> "src/*.c" pathspec. If it means that the user needs to type:
>
> $ git add src\\\\file.c
>
> I would have to say that it would be simpler for them to say
>
> $ git add src/file.c
>
> even on Cygwin. After all, isn't Cygwin for people who are forced to be on
> Windows and miss POSIXy environments?
>
> By the way, Johannes, how does Git for Windows handle pathspecs?
On Windows, prefix_filename() and prefix_path() (the latter via
normalize_path_copy()) transform any backslashes to forward-slashes.
Therefore, if you have src\*.c on the command line, it is processed as
src/*.c. That is, if \ was meant to escape the *, then this would not
work. It does not help to duplicate backslashes, because all of them are
transformed to forward-slashes before git's glob expansion kicks in.
-- Hannes
^ permalink raw reply
* [PATCH] git-reset.txt: Be clearer about the symbolic ref nature of HEAD
From: Michael J Gruber @ 2011-08-24 9:56 UTC (permalink / raw)
To: git
"git reset" updates the ref which HEAD points to (or HEAD itself, if
detached), due to being a symbolic ref (unless detached). Therefore,
"updating/resetting HEAD" is a possible source of confusion especially when
compared with "git checkout", and the change in
d537c74 (git-reset.txt: make modes description more consistent, 2010-09-15)
did not quite help.
Clean up after d537c74 (myself) and try to be even clearer about which
ref is changed by "git reset". Avoid the term "symbolic ref", because who can
tell *HEAD from HEAD from &HEAD?
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-reset.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index b2832fc..96c964d 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
-----------
In the first and second form, copy entries from <commit> to the index.
-In the third form, set the current branch head (HEAD) to <commit>, optionally
+In the third form, set the current branch head (which HEAD points to) to <commit>, optionally
modifying index and working tree to match. The <commit> defaults to HEAD
in all forms.
@@ -44,8 +44,9 @@ you can use it to selectively reset hunks. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.
'git reset' [--<mode>] [<commit>]::
- This form resets the current branch head to <commit> and
- possibly updates the index (resetting it to the tree of <commit>) and
+ This form resets the current branch head (which HEAD points to) to <commit>;
+ if HEAD points to a commit (aka detached HEAD) then HEAD is reset to <commit>.
+ This form also possibly updates the index (resetting it to the tree of <commit>) and
the working tree depending on <mode>, which
must be one of the following:
+
--
1.7.6.845.gc3c05
^ permalink raw reply related
* Re: Looking for a way to turn off/modify ref disambiguation
From: Michael J Gruber @ 2011-08-24 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathan W. Panike, git
In-Reply-To: <7vei0brdiq.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 24.08.2011 00:03:
> "Nathan W. Panike" <nathan.panike@gmail.com> writes:
>
>> 1. If $GIT_DIR/<name> exists, that is what you mean
>> (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD,
>> MERGE_HEAD and CHERRY_PICK_HEAD);
>> 2. otherwise, refs/<name> if it exists;
>> 3. otherwise, refs/tags/<refname> if it exists;
>> 4. otherwise, refs/heads/<name> if it exists;
>> 5. otherwise, refs/remotes/<name> if it exists;
>> 6. otherwise, refs/remotes/<name>/HEAD if it exists.
>> ...
>>
>> Is there any way to change this behavior, e.g., so that rule 6 becomes
>> an error?
>
> You will force people to say "git log origin/master..master" to measure
> their progress if you did so, when "git log origin..master" has been the
> way described in many git books and documentation pages floating on the
> web.
I haven't come across advice like that. In our own documentation, we
don't explain it, and in our user-manual "origin" is used as the name of
a branch.
I consider that advice very bad indeed:
If "origin..master" is resolved to "master ^origin/master", then
obviously "origin..next" is resolved to "next ^origin/next" - but it is
not, of course, and the fact that "origin" is resolved to
"origin/master" depends on the content of "origin/HEAD", which the
upstream repo owner controls (in the sense that upstream's HEAD
determines it), not downstream.
Thus, teaching "origin..master" as a way of measuring your progress is
grossly misleading. "@{u}.." does that when you're on the branch in
question, and we have no notation for "@{u(master)}..master".
Side note:
In fact, who groks symbolic refs anyway? I mean, git-reset sets HEAD and
git-checkout does so, right? ;)
(I'm afraid I need to clean up after myself in git-reset(1)...)
> I think it is _very_ unlikely that such a change is going to happen.
If messing with the origin..master notation is the only fall-out I'm all
for it.
But note that the OP only asked for a way to turn off disambiguation,
not for a change of defaults..
Michael
^ permalink raw reply
* Re: [PATCH 6/6] Retain caches of submodule refs
From: Michael Haggerty @ 2011-08-24 8:17 UTC (permalink / raw)
To: Heiko Voigt
Cc: git, Junio C Hamano, Jeff King, Drew Northup, Jakub Narebski,
Josh Triplett
In-Reply-To: <20110813125438.GC4783@book.hvoigt.net>
On 08/13/2011 02:54 PM, Heiko Voigt wrote:
> On Sat, Aug 13, 2011 at 12:36:29AM +0200, Michael Haggerty wrote:
>> diff --git a/refs.c b/refs.c
>> index 8d1055d..f02cf94 100644
>> --- a/refs.c
>> +++ b/refs.c
>
> ...
>
>> @@ -205,23 +208,28 @@ struct cached_refs *create_cached_refs(const char *submodule)
>> */
>> static struct cached_refs *get_cached_refs(const char *submodule)
>> {
>> - if (! submodule) {
>> - if (!cached_refs)
>> - cached_refs = create_cached_refs(submodule);
>> - return cached_refs;
>> - } else {
>> - if (!submodule_refs)
>> - submodule_refs = create_cached_refs(submodule);
>> - else
>> - /* For now, don't reuse the refs cache for submodules. */
>> - clear_cached_refs(submodule_refs);
>> - return submodule_refs;
>> + struct cached_refs *refs = cached_refs;
>> + if (! submodule)
>> + submodule = "";
>
> Maybe instead of searching for the main refs store a pointer to them
> locally so you can immediately return here. That will keep the
> performance when requesting the main refs the same.
I am assuming that the number of submodules will be small compared to
the number of refs in a typical submodule. Therefore, given that the
refs are stored in a big linked list and that the only thing that can
realistically be done with the list is to iterate through it, the cost
of finding the reference cache for a specific (sub-)module should be
negligible compared to the cost of the iteration over refs in the cache.
Treating the main module like the other submodules makes the code
simpler, so I would prefer to leave it this way.
If iteration over refs ever becomes a bottleneck, then optimization of
the storage of refs within a (sub-)module would be a bigger win than
special-casing the main module. And that is what I would like to work
towards.
> If I see it correctly you are always prepending to the linked list
This is true.
> and
> in case many submodules get cached this could slow down the iteration
> over the refs of the main repository.
Is this a realistic concern? Remember that the extra search over
submodules only occurs once for each scan through the list of references.
I wrote an additional patch that moves the least-recently accessed
module to the front of the list. But I doubt that the savings justify
the 10-odd extra lines of code, so I kept it to myself. Please note
that this approach gives pessimal performance (2x slower) if the
submodules are iterated over repeatedly. If you would like me to add
this patch to the patch series, please let me know.
Long-term, it would be better to implement a "struct submodule" and use
it to hold submodule-specific data like the ref cache. Then users could
hold on to the "struct submodule *" and pass it, rather than the
submodule name, to the functions that need it. But this goes beyond the
scope of what I want to change now, especially since I have no
experience even working with submodules.
Summary: I hope I have convinced you that the extra overhead is
negligible and does not justify additional code. But if you insist on
more emphasis on performance (or obviously if you have numbers to back
up your concerns) then I would be willing to put more work into it.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Looking for a way to turn off/modify ref disambiguation
From: Clemens Buchacher @ 2011-08-24 6:54 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <CAPRoxBXjL3Y3KRd8R2guX9Ar374sw-pBhz1bCzNZxn1vC6XNPw@mail.gmail.com>
Hi Nathan,
On Tue, Aug 23, 2011 at 02:26:48PM -0500, Nathan W. Panike wrote:
>
> Is there any way to change this behavior, e.g., so that rule 6 becomes
> an error? Say, by setting a config option?
I know you're trying to improve git. I do not want to discourage
that. But with little UI annoyances like this, it's usually not
worth it. Git has countless magic tricks like this. It's a bit
like perl in that regard. Assuming that we agree on what we would
like to get rid of (which is the hard part), it would still break
backwards compatibility. Maintaining a switch, on the other hand,
is overhead and in the end it would make git even more complicated,
because now the behavior of core commands depends on user
configuration.
But once you accept the fact that this is what git is, you can
tackle the problem in a different way:
> A colleague at $dayjob recently caused corruption in our git
> repository by accidentally running the command
>
> git rebase origin stable
Ok, mistakes happen. But that's exactly why you have git: To be
able to deal with mistakes gracefully. So use git to review and
test changes before they get declared as a stable release (stable
enough to be used internally, at least). Then mistakes usually
become a local problem and can be undone using the reflog.
Clemens
^ permalink raw reply
* Re: [PATCH v2] xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
From: Marat Radchenko @ 2011-08-24 6:32 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20110824T082807-840@post.gmane.org>
Marat Radchenko <marat <at> slonopotamus.org> writes:
> So, will this be applied to git master? Very impressive speed improvement.
Sorry, just discovered it is already in pu.
^ permalink raw reply
* Re: [PATCH v2] xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
From: Marat Radchenko @ 2011-08-24 6:29 UTC (permalink / raw)
To: git
In-Reply-To: <1313546037-4104-1-git-send-email-rctay89@gmail.com>
Tay Ray Chuan <rctay89 <at> gmail.com> writes:
> Here, we improve this to O(n) by pre-computing nm (in rcrec->len(1|2))
> in xdl_classify_record().
>
> Reported-by: Marat Radchenko <marat <at> slonopotamus.org>
> Signed-off-by: Tay Ray Chuan <rctay89 <at> gmail.com>
So, will this be applied to git master? Very impressive speed improvement.
^ permalink raw reply
* [PATCH] get_indexed_object can return NULL if nothing is in that slot; check for it
From: Brian Harring @ 2011-08-24 5:47 UTC (permalink / raw)
To: git
This fixes a segfault introduced by 051e400; via it, no longer able to
trigger the http/smartserv race.
Signed-off-by: Brian Harring <ferringb@gmail.com>
---
upload-pack.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 6420918..8739bfa 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -533,6 +533,8 @@ static void check_non_tip(void)
namebuf[41] = '\n';
for (i = get_max_object_index(); 0 < i; ) {
o = get_indexed_object(--i);
+ if (!o)
+ continue;
if (!(o->flags & OUR_REF))
continue;
memcpy(namebuf + 1, sha1_to_hex(o->sha1), 40);
--
1.7.6
^ permalink raw reply related
* Re: [PATCHv2 0/2] gitweb: Beginnings of splitting gitweb into modules
From: Pavan Kumar Sunkara @ 2011-08-24 2:17 UTC (permalink / raw)
To: Git List
In-Reply-To: <4E54102D.8060900@eaglescrag.net>
I can try to restart it. I had a lot of health issues last year, But I
am free now to finish this series.
On Wed, Aug 24, 2011 at 2:10 AM, J.H. <warthog9@eaglescrag.net> wrote:
> Pretty much stalled like most things on gitweb. I've been knee deep in
> a lot of GSoC stuff, conferences and dealing with kernel bugs and Jakub
> has been busy on other things so we haven't had a solid head bashing
> session to get this all worked out yet.
>
> Maybe while I'm over in Prague / Europe for KS & Linuxcon we can hash
> things out.
>
> - John 'Warthog9' Hawley
>
> On 08/23/2011 01:35 PM, Sylvain Rabot wrote:
>> Hi,
>>
>> Just wanted to know what is the current status of splitting gitweb
>> sources into modules.
>>
>> Regards.
>>
>> On Tue, 2011-05-03 at 16:04 +0200, Jakub Narebski wrote:
>>> Gitweb is currently next to largest file (after gitk) in git sources,
>>> more than 225KB with more than 7,000 lines. Therefore adding any
>>> large feature that would require large amount of code added, like
>>> gitweb caching by J.H. and my rewrite of it, or "gitweb admin/write"
>>> [failed] GSoC 2010 project by Pavan Kumar Sunkara, would require for
>>> new code to be added as a separate module. Otherwise gitweb would
>>> fast become unmaintainable.
>>>
>>> Note that there is already patch series sent which as one of side
>>> effects splits the JavaScript side of gitweb into many smaller
>>> self-contained files:
>>>
>>> [PATCH 03/13] gitweb: Split JavaScript for maintability, combining on build
>>> http://thread.gmane.org/gmane.comp.version-control.git/172384/focus=172385
>>>
>>> Not in all cases splitting gitweb upfront would be required. At least
>>> in the case of gitweb caching it doesn't. What must be done however
>>> is preparing the infrastructure for modular gitweb sources; to
>>> properly test such infrastructure we need at least one split gitweb
>>> module. With patch series preparing for splitting or true splitting of
>>> gitweb sent upfront the future patch series that implements
>>> code-extensive feature (like e.g. output caching) would be smaller and
>>> easier to review.
>>>
>>>
>>> This series is intended to bring such infrastructure to gitweb, to
>>> prepare way for adding output caching to gitweb. Alternatively it can
>>> be thought as beginning of splitting gitweb into smaller submodules,
>>> for better maintainability.
>>>
>>> This patch series was sent to git mailing list as
>>>
>>> [PATCH 0/2] gitweb: Begin splitting gitweb
>>> http://thread.gmane.org/gmane.comp.version-control.git/165824
>>>
>>> In the above mentioned first version of this series, the first patch
>>> that prepared the way for splitting gitweb was in three versions: A, B
>>> and C. In this second version of this series the first patch in
>>> series most closely resembles version C in v1 series.
>>>
>>> In this version gitweb uses _both_ 'use lib __DIR__."/lib";' and
>>> 'use lib "++GITWEBLIBDIR++";', in correct order (as compared to
>>> version C of v1 series), so that __DIR__."/lib" is checked first,
>>> i.e. modules installed alongside gitweb.cgi win.
>>>
>>> Pull request:
>>> ~~~~~~~~~~~~~
>>> This series is available in the git repository at:
>>> git://repo.or.cz/git/jnareb-git.git gitweb/split
>>> git://github.com/jnareb/git.git gitweb/split
>>>
>>> Well, those patches has a few minor cosmetic fixups...
>>>
>>> Table of contents:
>>> ~~~~~~~~~~~~~~~~~~
>>> * [PATCHv2 1/2] gitweb: Prepare for splitting gitweb
>>> [PATCHv2 2/2] gitweb: Create Gitweb::Util module
>>>
>>> First patch implements infrastructure, second proof of concept patch uses
>>> this infrastructure, testing it ("make -C gitweb test-installed").
>>>
>>> Shortlog:
>>> ~~~~~~~~~
>>> Jakub Narebski (1):
>>> gitweb: Prepare for splitting gitweb
>>>
>>> Pavan Kumar Sunkara (1):
>>> gitweb: Create Gitweb::Util module
>>>
>>> Diffstat:
>>> ~~~~~~~~~
>>> gitweb/INSTALL | 7 ++
>>> gitweb/Makefile | 23 ++++++-
>>> gitweb/gitweb.perl | 151 ++++-----------------------------------
>>> gitweb/lib/Gitweb/Util.pm | 177 +++++++++++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 219 insertions(+), 139 deletions(-)
>>> create mode 100755 gitweb/lib/Gitweb/Util.pm
>>>
>>
>
>
--
- Pavan Kumar Sunkara
^ permalink raw reply
* Re: git for game development?
From: Jeff King @ 2011-08-24 1:24 UTC (permalink / raw)
To: Lawrence Brett; +Cc: git
In-Reply-To: <416D1A48-9916-4E44-A200-3A13C39C4D70@gmail.com>
On Tue, Aug 23, 2011 at 04:06:47PM -0700, Lawrence Brett wrote:
> I am very interested in using git for game development. I will be working
> with a lot of binaries (textures, 3d assets, etc.) in addition to source
> files. I'd like to be able to version these files, but I understand that
> big binaries aren't git's forte. I've found several possible workarounds
> (git submodules, git-media, git-annex), but the one that seems most
> promising is bup. I started a thread on the bup mailing list to ask about
> the best way to use bup with git for my purposes. One of the respondents
> suggested forking git itself to include bup functionality, thereby extending
> git to handle binaries efficiently.
>
> My question for this group is: would there be interest in incorporating
> this sort of functionality into git core? I would certainly find it
> compelling as a user, but have no idea how it would fit into the bigger
> picture.
Something bup-like in git-core might eventually be good. But IIRC, bup
introduces new object types, which mixes the abstract view of the data
format (i.e., commits, trees, and blobs indexed by sha1) with the
implementation details (e.g., now we have both loose objects in their
own files as well as delta-compressed objects in packfiles).
That means that bup-git clients and non-bup git clients don't interact
very well. Where non-bup is either a client that doesn't understand the
bup objects, or one that chooses not to use bup-like encoding for
particular blobs.
I don't remember all of the details of bup, but if it's possible to
implement something similar at a lower level (i.e., at the layer of
packfiles or object storage), then it can be a purely local thing, and
the compatibility issues can go away.
-Peff
PS I also agree with Junio's comment that we are not at the "planning a
solution" stage with big files, but rather at the "trying it and getting
experience on what works and what doesn't" stage.
^ permalink raw reply
* [PATCH] Documentation: Grammar correction, wording fixes and cleanup
From: Ben Walton @ 2011-08-24 0:32 UTC (permalink / raw)
To: gitster; +Cc: drew.northup, git, Ben Walton
In-Reply-To: <7vliujre93.fsf@alter.siamese.dyndns.org>
Correct a few grammar issues in gitrepository-layout.txt and also
rewords a few sections for clarity.
Remove references to using http-fetch without -a to create a broken
repository.
Mark a few areas of the repository structure as legacy.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
Documentation/gitrepository-layout.txt | 58 +++++++++++++++-----------------
1 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index eb3d040..5c891f1 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -23,32 +23,25 @@ objects::
Object store associated with this repository. Usually
an object store is self sufficient (i.e. all the objects
that are referred to by an object found in it are also
- found in it), but there are couple of ways to violate
- it.
+ found in it), but there are a few ways to violate it.
+
-. You could populate the repository by running a commit walker
-without `-a` option. Depending on which options are given, you
-could have only commit objects without associated blobs and
-trees this way, for example. A repository with this kind of
-incomplete object store is not suitable to be published to the
-outside world but sometimes useful for private repository.
-. You also could have an incomplete but locally usable repository
-by cloning shallowly. See linkgit:git-clone[1].
-. You can be using `objects/info/alternates` mechanism, or
-`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
+. You could have an incomplete but locally usable repository
+by creating a shallow clone. See linkgit:git-clone[1].
+. You could be using the `objects/info/alternates` or
+`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
objects from other object stores. A repository with this kind
of incomplete object store is not suitable to be published for
use with dumb transports but otherwise is OK as long as
-`objects/info/alternates` points at the right object stores
-it borrows from.
+`objects/info/alternates` points at the object stores it
+borrows from.
objects/[0-9a-f][0-9a-f]::
- Traditionally, each object is stored in its own file.
- They are split into 256 subdirectories using the first
- two letters from its object name to keep the number of
- directory entries `objects` directory itself needs to
- hold. Objects found here are often called 'unpacked'
- (or 'loose') objects.
+ A newly created object is stored in its own file.
+ The objects are splayed over 256 subdirectories using
+ the first two characters of the sha1 object name to
+ keep the number of directory entries in `objects`
+ itself to a manageable number. Objects found
+ here are often called 'unpacked' (or 'loose') objects.
objects/pack::
Packs (files that store many object in compressed form,
@@ -85,7 +78,7 @@ objects/info/http-alternates::
refs::
References are stored in subdirectories of this
- directory. The 'git prune' command knows to keep
+ directory. The 'git prune' command knows to preserve
objects reachable from refs found in this directory and
its subdirectories.
@@ -119,16 +112,17 @@ HEAD::
+
HEAD can also record a specific commit directly, instead of
being a symref to point at the current branch. Such a state
-is often called 'detached HEAD', and almost all commands work
-identically as normal. See linkgit:git-checkout[1] for
-details.
+is often called 'detached HEAD.' See linkgit:git-checkout[1]
+for details.
branches::
A slightly deprecated way to store shorthands to be used
- to specify URL to 'git fetch', 'git pull' and 'git push'
- commands is to store a file in `branches/<name>` and
- give 'name' to these commands in place of 'repository'
- argument.
+ to specify a URL to 'git fetch', 'git pull' and 'git push'.
+ A file can be stored as `branches/<name>` and then
+ 'name' can be given to these commands in place of
+ 'repository' argument. See the REMOTES section in
+ linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories.
hooks::
Hooks are customization scripts used by various git
@@ -173,9 +167,11 @@ info/exclude::
at it. See also: linkgit:gitignore[5].
remotes::
- Stores shorthands to be used to give URL and default
- refnames to interact with remote repository to
- 'git fetch', 'git pull' and 'git push' commands.
+ Stores shorthands for URL and default refnames for use
+ when interacting with remote repositories via 'git fetch',
+ 'git pull' and 'git push' commands. See the REMOTES section
+ in linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories.
logs::
Records of changes made to refs are stored in this
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Mark http-fetch without -a as deprecated
From: Ben Walton @ 2011-08-24 0:29 UTC (permalink / raw)
To: gitster; +Cc: git, Matthieu.Moy, Ben Walton
In-Reply-To: <vpqvcto391x.fsf@bauges.imag.fr>
As the use of http-fetch without -a can create an object store that is
invalid to the point where it cannot even be fsck'd, mark it as
deprecated. A future release should change the default and then
remove the option entirely.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
Documentation/git-http-fetch.txt | 3 +++
http-fetch.c | 4 ++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
index 4d42073..070cd1e 100644
--- a/Documentation/git-http-fetch.txt
+++ b/Documentation/git-http-fetch.txt
@@ -15,6 +15,9 @@ DESCRIPTION
-----------
Downloads a remote git repository via HTTP.
+*NOTE*: use of this command without -a is deprecated. The -a
+behaviour will become the default in a future release.
+
OPTIONS
-------
commit-id::
diff --git a/http-fetch.c b/http-fetch.c
index 3af4c71..8c4c5d2 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -56,6 +56,10 @@ int main(int argc, const char **argv)
commits = 1;
}
+ if (get_all == 0)
+ warning("http-fetch: use without -a is deprecated.\n"
+ "In a future release, -a will become the default.");
+
if (argv[arg])
str_end_url_with_slash(argv[arg], &url);
--
1.7.4.1
^ permalink raw reply related
* What's cooking in git.git (Aug 2011, #06; Tue, 23)
From: Junio C Hamano @ 2011-08-23 23:47 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I was very tempted to cut 1.7.7-rc0 today, but we have quite a few topics
that deserve to be in the upcoming release and are still in 'next'. I'll
probably merge most if not all of what are in 'next' as of today sometime
later this week, tag a 1.7.7-rc0 release and declare feature freeze for
this cycle.
--------------------------------------------------
[Graduated to "master"]
* cb/maint-ls-files-error-report (2011-08-11) 1 commit
(merged to 'next' on 2011-08-15 at 69f41cf)
+ ls-files: fix pathspec display on error
* jn/maint-test-return (2011-08-11) 3 commits
(merged to 'next' on 2011-08-15 at 5a42301)
+ t3900: do not reference numbered arguments from the test script
+ test: cope better with use of return for errors
+ test: simplify return value of test_run_
* rt/zlib-smaller-window (2011-08-11) 2 commits
(merged to 'next' on 2011-08-15 at e05b26b)
+ test: consolidate definition of $LF
+ Tolerate zlib deflation with window size < 32Kb
--------------------------------------------------
[New Topics]
* fk/use-kwset-pickaxe-grep-f (2011-08-20) 5 commits
(merged to 'next' on 2011-08-23 at 93ba509)
+ Use kwset in grep
+ Use kwset in pickaxe
+ Adapt the kwset code to Git
+ Add string search routines from GNU grep
+ Add obstack.[ch] from EGLIBC 2.10
* jc/maint-autofix-tag-in-head (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at 18cee02)
+ commit: reduce use of redundant global variables
* bw/doc-repo-layout (2011-08-22) 2 commits
- Mark http-fetch without -a as deprecated
- Documentation: Grammar correction, wording fixes and cleanup
* ci/forbid-unwanted-current-branch-update (2011-08-22) 2 commits
- Show interpreted branch name in error messages
- Prevent force-updating of the current branch
* di/fast-import-blob-tweak (2011-08-22) 2 commits
- fast-import: treat cat-blob as a delta base hint for next blob
- fast-import: count and report # of calls to diff_delta in stats
* jc/combine-diff-callback (2011-08-20) 1 commit
- combine-diff: support format_callback
(this branch is used by fg/submodule-ff-check-before-push.)
* jc/maint-clone-alternates (2011-08-23) 2 commits
(merged to 'next' on 2011-08-23 at 7280deb)
+ clone: clone from a repository with relative alternates
+ clone: allow more than one --reference
* nd/maint-clone-gitdir (2011-08-22) 2 commits
- clone: allow to clone from .git file
- read_gitfile_gently(): rename misnamed function to read_gitfile()
* di/fast-import-tagging (2011-08-23) 2 commits
- fast-import: allow to tag newly created objects
- fast-import: add tests for tagging blobs
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates.
* jc/merge-reword (2011-05-25) 2 commits
- merge: mark the final "Merge made by..." message for l10n
- merge: reword the final message
Probably the topmost commit should be dropped.
* nk/branch-v-abbrev (2011-07-01) 1 commit
- branch -v: honor core.abbrev
Perhaps needs an updated commit log message?
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* jc/traverse-commit-list (2011-08-22) 3 commits
- revision.c: update show_object_with_name() without using malloc()
- revision.c: add show_object_with_name() helper function
- rev-list: fix finish_object() call
* rc/diff-cleanup-records (2011-08-17) 2 commits
(merged to 'next' on 2011-08-23 at b8414f5)
+ Merge branch 'rc/histogram-diff' into HEAD
+ xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
- Makefile: Use computed header dependencies if the compiler supports it
* jk/color-and-pager (2011-08-19) 10 commits
(merged to 'next' on 2011-08-23 at cbb9495)
+ want_color: automatically fallback to color.ui
+ diff: don't load color config in plumbing
+ config: refactor get_colorbool function
+ color: delay auto-color decision until point of use
+ git_config_colorbool: refactor stdout_is_tty handling
+ diff: refactor COLOR_DIFF from a flag into an int
+ setup_pager: set GIT_PAGER_IN_USE
+ t7006: use test_config helpers
+ test-lib: add helper functions for config
+ t7006: modernize calls to unset
(this branch is used by jk/pager-with-alias.)
* jk/pager-with-alias (2011-08-19) 2 commits
- support pager.* for aliases
- support pager.* for external commands
(this branch uses jk/color-and-pager.)
* nd/decorate-grafts (2011-08-19) 5 commits
(merged to 'next' on 2011-08-23 at 475d27e)
+ log: decorate "replaced" on to replaced commits
+ log: decorate grafted commits with "grafted"
+ Move write_shallow_commits to fetch-pack.c
+ Add for_each_commit_graft() to iterate all grafts
+ decoration: do not mis-decorate refs with same prefix
* va/p4-branch-import (2011-08-22) 4 commits
- git-p4: Add simple test case for branch import
- git-p4: Allow branch definition with git config
- git-p4: Allow filtering Perforce branches by user
- git-p4: Correct branch base depot path detection
(this branch uses va/p4-rename-copy.)
* va/p4-rename-copy (2011-08-22) 5 commits
- git-p4: Process detectCopiesHarder with --bool
- git-p4: Add test case for copy detection
- git-p4: Add test case for rename detection
- git-p4: Add description of rename/copy detection options
- git-p4: Allow setting rename/copy detection threshold
(this branch is used by va/p4-branch-import.)
* da/difftool-mergtool-refactor (2011-08-19) 4 commits
(merged to 'next' on 2011-08-23 at a1cc3be)
+ mergetools/meld: Use '--output' when available
+ mergetool--lib: Refactor tools into separate files
+ mergetool--lib: Make style consistent with git
+ difftool--helper: Make style consistent with git
* mg/branch-set-upstream-previous (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at acef0b6)
+ branch.c: use the parsed branch name
* di/fast-import-doc (2011-08-17) 1 commit
(merged to 'next' on 2011-08-23 at dab4088)
+ doc/fast-import: document feature import-marks-if-exists
* di/fast-import-deltified-tree (2011-08-14) 2 commits
(merged to 'next' on 2011-08-23 at ee30265)
+ fast-import: prevent producing bad delta
+ fast-import: add a test for tree delta base corruption
* di/fast-import-ident (2011-08-11) 5 commits
(merged to 'next' on 2011-08-23 at 9b86391)
+ fsck: improve committer/author check
+ fsck: add a few committer name tests
+ fast-import: check committer name more strictly
+ fast-import: don't fail on omitted committer name
+ fast-import: add input format tests
* di/parse-options-split (2011-08-11) 2 commits
(merged to 'next' on 2011-08-23 at 6cd667f)
+ Reduce parse-options.o dependencies
+ parse-options: export opterr, optbug
* mh/attr (2011-08-14) 7 commits
(merged to 'next' on 2011-08-23 at 22faa6e)
+ Unroll the loop over passes
+ Change while loop into for loop
+ Determine the start of the states outside of the pass loop
+ Change parse_attr() to take a pointer to struct attr_state
+ Increment num_attr in parse_attr_line(), not parse_attr()
+ Document struct match_attr
+ Add a file comment
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything wrong per-se, but it was unclear what the benefit
of these changes are.
* jn/plug-empty-tree-leak (2011-08-16) 2 commits
(merged to 'next' on 2011-08-23 at aee2184)
+ merge-recursive: take advantage of hardcoded empty tree
+ revert: plug memory leak in "cherry-pick root commit" codepath
* ac/describe-dirty-refresh (2011-08-11) 1 commit
(merged to 'next' on 2011-08-23 at b873611)
+ describe: Refresh the index when run with --dirty
* en/merge-recursive-2 (2011-08-14) 57 commits
(merged to 'next' on 2011-08-23 at ba6ad0d)
+ merge-recursive: Don't re-sort a list whose order we depend upon
+ merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest
+ t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify
+ merge-recursive: Avoid unnecessary file rewrites
+ t6022: Additional tests checking for unnecessary updates of files
+ merge-recursive: Fix spurious 'refusing to lose untracked file...' messages
+ t6022: Add testcase for spurious "refusing to lose untracked" messages
+ t3030: fix accidental success in symlink rename
+ merge-recursive: Fix working copy handling for rename/rename/add/add
+ merge-recursive: add handling for rename/rename/add-dest/add-dest
+ merge-recursive: Have conflict_rename_delete reuse modify/delete code
+ merge-recursive: Make modify/delete handling code reusable
+ merge-recursive: Consider modifications in rename/rename(2to1) conflicts
+ merge-recursive: Create function for merging with branchname:file markers
+ merge-recursive: Record more data needed for merging with dual renames
+ merge-recursive: Defer rename/rename(2to1) handling until process_entry
+ merge-recursive: Small cleanups for conflict_rename_rename_1to2
+ merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
+ merge-recursive: Introduce a merge_file convenience function
+ merge-recursive: Fix modify/delete resolution in the recursive case
+ merge-recursive: When we detect we can skip an update, actually skip it
+ merge-recursive: Provide more info in conflict markers with file renames
+ merge-recursive: Cleanup and consolidation of rename_conflict_info
+ merge-recursive: Consolidate process_entry() and process_df_entry()
+ merge-recursive: Improve handling of rename target vs. directory addition
+ merge-recursive: Add comments about handling rename/add-source cases
+ merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
+ merge-recursive: Fix deletion of untracked file in rename/delete conflicts
+ merge-recursive: Split update_stages_and_entry; only update stages at end
+ merge-recursive: Allow make_room_for_path() to remove D/F entries
+ string-list: Add API to remove an item from an unsorted list
+ merge-recursive: Split was_tracked() out of would_lose_untracked()
+ merge-recursive: Save D/F conflict filenames instead of unlinking them
+ merge-recursive: Fix code checking for D/F conflicts still being present
+ merge-recursive: Fix sorting order and directory change assumptions
+ merge-recursive: Fix recursive case with D/F conflict via add/add conflict
+ merge-recursive: Avoid working directory changes during recursive case
+ merge-recursive: Remember to free generated unique path names
+ merge-recursive: Consolidate different update_stages functions
+ merge-recursive: Mark some diff_filespec struct arguments const
+ merge-recursive: Correct a comment
+ merge-recursive: Make BUG message more legible by adding a newline
+ t6022: Add testcase for merging a renamed file with a simple change
+ t6022: New tests checking for unnecessary updates of files
+ t6022: Remove unnecessary untracked files to make test cleaner
+ t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
+ t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
+ t6036: tests for criss-cross merges with various directory/file conflicts
+ t6036: criss-cross with weird content can fool git into clean merge
+ t6036: Add differently resolved modify/delete conflict in criss-cross test
+ t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
+ t6042: Ensure rename/rename conflicts leave index and workdir in sane state
+ t6042: Add tests for content issues with modify/rename/directory conflicts
+ t6042: Add a testcase where undetected rename causes silent file deletion
+ t6042: Add a pair of cases where undetected renames cause issues
+ t6042: Add failing testcase for rename/modify/add-source conflict
+ t6042: Add a testcase where git deletes an untracked file
* fg/submodule-ff-check-before-push (2011-08-20) 2 commits
- push: teach --recurse-submodules the on-demand option
- push: Don't push a repository with unpushed submodules
(this branch uses jc/combine-diff-callback.)
* hv/submodule-update-none (2011-08-11) 2 commits
- add update 'none' flag to disable update of submodule by default
- submodule: move update configuration variable further up
Will merge to "next".
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
* js/i18n-scripts (2011-08-08) 5 commits
(merged to 'next' on 2011-08-23 at a1b5529)
+ submodule: take advantage of gettextln and eval_gettextln.
+ stash: take advantage of eval_gettextln
+ pull: take advantage of eval_gettextln
+ git-am: take advantage of gettextln and eval_gettextln.
+ gettext: add gettextln, eval_gettextln to encode common idiom
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
- revert: Propagate errors upwards from do_pick_commit
- revert: Introduce --continue to continue the operation
- revert: Don't implicitly stomp pending sequencer operation
- revert: Remove sequencer state when no commits are pending
- reset: Make reset remove the sequencer state
- revert: Introduce --reset to remove sequencer state
- revert: Make pick_commits functionally act on a commit list
- revert: Save command-line options for continuing operation
- revert: Save data for continuing after conflict resolution
- revert: Don't create invalid replay_opts in parse_args
- revert: Separate cmdline parsing from functional code
- revert: Introduce struct to keep command-line options
- revert: Eliminate global "commit" variable
- revert: Rename no_replay to record_origin
- revert: Don't check lone argument in get_encoding
- revert: Simplify and inline add_message_to_msg
- config: Introduce functions to write non-standard file
- advice: Introduce error_resolve_conflict
Will merge to "next".
^ permalink raw reply
* Re: git for game development?
From: Junio C Hamano @ 2011-08-23 23:32 UTC (permalink / raw)
To: Lawrence Brett; +Cc: git
In-Reply-To: <416D1A48-9916-4E44-A200-3A13C39C4D70@gmail.com>
Lawrence Brett <lcbrett@gmail.com> writes:
> My question for this group is: would there be interest in incorporating
> this sort of functionality into git core? I would certainly find it
> compelling as a user, but have no idea how it would fit into the bigger
> picture.
I personally think it is too early for you to ask that question; until you
set up a workable workflow around bup or a combination of bup and git, get
used to its use, and find out what the real pain points are if you used
only git without bup, that is.
Efforts to tweak tools by people who are not yet familiar with the tools
they are trying to use unfortunately often tend to go in wrong directions
and become wasted effort.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import
From: Pete Wyckoff @ 2011-08-23 23:10 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Tor Arvid Lund
In-Reply-To: <CAOpHH-V92CcWm1tCwvb=pJux5PKbYQoG=E8M_Pc2JGu00wnR8Q@mail.gmail.com>
vitor.hda@gmail.com wrote on Tue, 23 Aug 2011 23:02 +0100:
> On Tue, Aug 23, 2011 at 3:27 AM, Pete Wyckoff <pw@padd.com> wrote:
> > I think I understand the problem now, and have a small test case
> > to see what's going wrong. Your solution is definitely
> > sub-optimal. :) Is there anything that can be done with
> > --import-marks and --export-marks?
>
> Don't know if you agree, but I think it would be better to keep git-p4
> from storing extra files in the filesystem. And, as far as I understood,
> these two options require extra files.
> But I don't think marks would help us that much. We already have
> something similar: the changelist number in the commit log. The big
> problem is that P4 does not store a pointer to the previous changelist.
Agreed.
> > Could you guess at the branch point using p4? I.e. for each file
> > in the new branch, grab the change that caused its most recent
> > revision (the #xx part). Pick the max of those changes. In git,
> > find the commit whith "change = ..." that you just discovered.
> > That's the parent.
>
> Yes, I think this would work. Nevertheless, I would prefer not to do so
> much pooling on the P4 server because when we're in a remote location in
> regards to the P4 proxy server this kind of command becomes rather slow.
> And if the branch has many files this may become cumbersome.
>
> > Even this won't be perfect, and I'm not even sure if it's less
> > icky than diff-tree.
>
> From what I can see, the two possible solutions would be:
>
> a) Running a "filelog" on all files. This may become slower when the
> branch has lots of files. There's also the problem in needing to
> contact the P4 proxy server every time.
>
> b) Using diff-tree. This will be slower if the original changelist is
> very far from the latest one, but has the advantage of being run
> locally. It has the disadvantage of not having an apparent
> compatibility with fast-import.
>
> In my personal point of view, diff-tree solution still looks better, if
> it weren't for the fast-import issue. Now if we could just figure out
> how to overcome this issue...
Nice analysis. P4 can indeed be the bottleneck, even on near
servers if there are lots of files. Diff-tree seems like the
better choice to find the branch point. I don't understand fully
why the way we are using fast-import causes these problems. Will
look at that next.
-- Pete
^ permalink raw reply
* git for game development?
From: Lawrence Brett @ 2011-08-23 23:06 UTC (permalink / raw)
To: git
Hello,
I am very interested in using git for game development. I will be working
with a lot of binaries (textures, 3d assets, etc.) in addition to source
files. I'd like to be able to version these files, but I understand that
big binaries aren't git's forte. I've found several possible workarounds
(git submodules, git-media, git-annex), but the one that seems most
promising is bup. I started a thread on the bup mailing list to ask about
the best way to use bup with git for my purposes. One of the respondents
suggested forking git itself to include bup functionality, thereby extending
git to handle binaries efficiently.
My question for this group is: would there be interest in incorporating
this sort of functionality into git core? I would certainly find it
compelling as a user, but have no idea how it would fit into the bigger
picture.
Thanks in advance!
Cliff
P.S. I also heartily welcome any advice/insight on my use case. :-)
^ permalink raw reply
* Re: [PATCH v3 0/4] git-p4: Improve branch support
From: Vitor Antunes @ 2011-08-23 22:32 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110820191407.GD7135@arf.padd.com>
On Sat, Aug 20, 2011 at 8:14 PM, Pete Wyckoff <pw@padd.com> wrote:
> In particular, a clear case of how to set up the branches for
> the branchList example would be good. My minimal test did not
> exactly work.
Could you send me the list of steps you followed that resulted in git-p4
failing to detect the branches?
Thanks,
--
Vitor Antunes
^ 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