* Двери любые цена на 5 0 н иже 495 74090-44
From: Gennady @ 2011-08-16 13:29 UTC (permalink / raw)
To: git, git
Двери входные для любых помещений
отличная скидка 50 сегодня
495 7409022
http://clck.ru/ImPi
^ permalink raw reply
* Супер двери почти без денег 495 номер 740-90-22
From: Aleksashin Gennady @ 2003-12-31 18:46 UTC (permalink / raw)
To: git, git
Помещения двери вход
очень не дорого до 50 скидка
4 9 5 740-9044
http://u.to/Zn4gAQ
^ permalink raw reply
* Позвони двери почти бесплатно 4 9 5 740-9044
From: Aafgd @ 2011-08-15 14:56 UTC (permalink / raw)
To: git, git
Двери вход
почти бесплатно
4 95 74-09022
http://u.to/Zn4gAQ
^ permalink raw reply
* Re: [PATCH] update-index: add --swap to swap index and worktree content
From: Michael J Gruber @ 2011-08-16 13:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313158058-7684-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy venit, vidit, dixit 12.08.2011 16:07:
> Sometimes "git add -p" with "e" to edit the patch does not satisfy me.
> What I want is a quick way to modify index content without changing
> worktree, then I can continue adding more hunks to the index.
>
> With this option, I can swap index out for a quick edit, then swap it in
> again.
I had to think about that explanation for a while (partly because "git
add" does not alter the wt either). So, your patch would support the
following workflow:
git add foo # have index == wt
hack foo # change foo in wt
git update-index --swap foo # add foo and reset to previous state
Am I understanding you right? The option could trickle down to "add".
I share the pov that "add -p with e" sometimes doesn't cut it. But
similarly, the fact that "add -p" can't be used to undo a previous "add
-p" is suboptimal. Both issues could be solved with a 3way stage tool. I
have this on my todo/wish list, and I seem to recall that Jeff or Junio
came up with a few lines of (scripting) code for that. That would depend
on the availability of proper tools, though (e.g. vim in diff mode).
--swap might be useful nevertheless.
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Not sure if anybody has the same needs, enough to polish it and make
> it to master.
>
> builtin/update-index.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index a6a23fa..b96065a 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -22,6 +22,7 @@
> static int allow_add;
> static int allow_remove;
> static int allow_replace;
> +static int swap_entry;
> static int info_only;
> static int force_remove;
> static int verbose;
> @@ -104,6 +105,19 @@ static int add_one_path(struct cache_entry *old, const char *path, int len, stru
> free(ce);
> return -1;
> }
> + if (swap_entry) {
> + struct checkout state;
> + if (allow_add || allow_remove)
> + die("--add, --replace and --swap do not play together");
> + memset(&state, 0, sizeof(state));
> + state.force = 1;
> + state.not_new = 1;
> + if (add_cache_entry(ce, 0))
> + return error("%s: cannot add to the index", path);
> + if (checkout_entry(old, &state, NULL))
> + return error("%s: cannot swap", path);
> + return 0;
> + }
> option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
> option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
> if (add_cache_entry(ce, option))
> @@ -727,6 +741,8 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
> "let files replace directories and vice-versa", 1),
> OPT_SET_INT(0, "remove", &allow_remove,
> "notice files missing from worktree", 1),
> + OPT_SET_INT(0, "swap", &swap_entry,
> + "swap the content of index and worktree", 1),
> OPT_BIT(0, "unmerged", &refresh_args.flags,
> "refresh even if index contains unmerged entries",
> REFRESH_UNMERGED),
^ permalink raw reply
* Re: [PATCH] commit: check return value of lookup_commit()
From: Nguyen Thai Ngoc Duy @ 2011-08-16 13:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vei0mlg8d.fsf@alter.siamese.dyndns.org>
2011/8/16 Junio C Hamano <gitster@pobox.com>:
> The change itself looks good to me but a point and a half to think about:
>
> - In this if/elseif/.../else cascade, everybody except for the
> "initial_commit" case needs to make sure that head_sha1 points at a
> valid commit and get an commit object. Hoisting the scope of the
> variable "commit" one level in your patch is good, but it would make it
> easier to read and the future code modification much less error prone
> if (1) you called lookup_commit() and checked for errors before
> entering this if/elseif/... cascade, and (2) you renamed this variable
> to "head_commit".
But then I would need to avoid die()ing in "initial_commit" case. So
it becomes two related condition blocks (head_commit check and the
if/elseif...), more error prone to me.
> - Whether we like it or not, many people have a broken reimplementations
> of git that can put a non-commit in HEAD, and they won't be fixed
> overnight. Instead of erroring out, would it be nicer of us if we just
> warned, unwrapped the tag and used the tagged commit instead?
How about replacing those lookup_commit() with this? It would tolerate
tag-in-branch case, but also warn users that something's gone wrong.
struct commit *lookup_expect_commit(const unsigned char *sha1,
const char *ref_name)
{
struct commit *c = lookup_commit_reference(sha1);
if (!c)
die(_("could not parse %s"), ref_name);
if (hashcmp(sha1, c->object.sha1))
warning(_("%s %s is not a commit!"),
ref_name, sha1_to_hex(sha1));
return c;
}
--
Duy
^ permalink raw reply
* Входные двери очень не дорого до 50 скидка 4-9-5 740-90-44
From: Arabov Gennady @ 2011-08-16 13:30 UTC (permalink / raw)
To: git, git
Все двери
отличная скидка 50 сегодня
495 номер 740-90-22
http://clck.ru/ImPi
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Michael J Gruber @ 2011-08-16 13:37 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Schubert, git
In-Reply-To: <20110804040646.GA5104@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.08.2011 06:06:
> On Tue, Aug 02, 2011 at 07:17:38PM +0200, Michael Schubert wrote:
>
>> @@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
>> if ((kind & ref_list->kinds) == 0)
>> return 0;
>>
>> + if (cb->remote && strncmp(cb->remote, refname, strlen(cb->remote)))
>> + return 0;
>> +
>
> This isn't right. You are assuming that a remote called "foo" will have
> all of its branches in refs/remotes/foo. That's true under the default
> configuration, but technically speaking, the remote tracking branches of
> "foo" are defined by the right-hand side of foo's fetch refspecs.
You are 100% right here, but...
> So I think you want something more like this:
...the op still might want to filter simply by the remote name.
Reminds me that I have to resurrect my patterns-with-branches series....
Michael
^ permalink raw reply
* Нужна входная дверь скидка 50 4 9 5 740-9044
From: Aleksashin @ 2011-08-16 14:54 UTC (permalink / raw)
To: git, git
Супер не дорогие двери
50 скидка сейчас же
495 7409022
http://clck.ru/ImPi
^ permalink raw reply
* Re: RFC: repository of handy git aliases?
From: Michael J Gruber @ 2011-08-16 13:55 UTC (permalink / raw)
To: Jon Seymour; +Cc: Jakub Narębski, Git Mailing List
In-Reply-To: <CAH3AnrrNPBNNNr7Lm2-vnqOisxWorF4FS32H+LBaybWF3KdnGg@mail.gmail.com>
Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
>
> I've also added this...
>
> Listing the tips of branches in pu that are not in master
> ===========================================
>
> Suppose you have two aliases defined like so:
>
> [alias]
> oneline = !/usr/bin/xargs -L1 git log --decorate --max-count=1 --oneline
How about
oneline = git log --no-walk --decorate --oneline
> tips = "!_() { t=$(git rev-list --no-merges --max-count=1
> \"$@\"); if test -n \"$t\"; then echo $t; _ \"$@\" ^$t; fi; }; _"
>
That one is way over my head, but if
> Then:
>
> git tips origin/pu ^origin/next | git oneline
is your typical use case you may like
git branch --merged origin/pu --contains origin/next
(or with --no-merged, but put it first.)
> might show something like this:
>
> 9dcca58 filter-branch.sh: de-dent usage string
> 704c335 On Cygwin support both UNIX and DOS style path-names
> 1c460f9 t3030: fix accidental success in symlink rename
> 9e81372 test-path-utils: Add subcommand "prefix_path"
> ad733bd revert: Propagate errors upwards from do_pick_commit
> 76cf946 fixup! xdiff/xhistogram: rework handling of recursed results
> df6a9c7 fixup! describe: Refresh the index when run with --dirty
> c9f57a0 squash! ls-files: fix pathspec display on error
> a1288bc add--interactive: add option to autosplit hunks
> 365b78a t5800: point out that deleting branches does not work
> c997182 limit "contains" traversals based on commit generation
> 914b6fb doc/fast-import: document feature import-marks-if-exists
> b792c06 branch -v: honor core.abbrev
> b166408 mergetool: Don't assume paths are unmerged
> b29d76f merge: mark the final "Merge made by..." message for l10n
> 942cf39 receive-pack: Allow server to refuse pushes with too many objects
>
> which is a list of the tips of branches that are in pu, but not in next.
That's not quite the standard --decorate, is it? ;)
Michael
^ permalink raw reply
* Нужна входная дверь нет ценны ниже чем у нас (926) 011-32-44
From: Gennady @ 2002-01-02 2:33 UTC (permalink / raw)
To: git, git
Дверь отличная цена не заграничная
дешево
495 7409022
http://b23.ru/nos6
^ permalink raw reply
* Супер двери сразу и без денег (495) 740-90-22
From: Aafgd Gennady @ 2011-08-16 14:10 UTC (permalink / raw)
To: git, git
Любые двери которые вы можете себе представить
скидка 50
(926) 011-32-44
http://u.to/Zn4gAQ
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Michael Schubert @ 2011-08-16 14:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <4E4A729D.9030906@drmicha.warpmail.net>
On 08/16/2011 03:37 PM, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 04.08.2011 06:06:
>> On Tue, Aug 02, 2011 at 07:17:38PM +0200, Michael Schubert wrote:
>>
>>> @@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
>>> if ((kind & ref_list->kinds) == 0)
>>> return 0;
>>>
>>> + if (cb->remote && strncmp(cb->remote, refname, strlen(cb->remote)))
>>> + return 0;
>>> +
>>
>> This isn't right. You are assuming that a remote called "foo" will have
>> all of its branches in refs/remotes/foo. That's true under the default
>> configuration, but technically speaking, the remote tracking branches of
>> "foo" are defined by the right-hand side of foo's fetch refspecs.
>
> You are 100% right here, but...
>
>> So I think you want something more like this:
>
> ...the op still might want to filter simply by the remote name.
There's an interesting discussion related to the subject:
http://thread.gmane.org/gmane.comp.version-control.git/178960
^ permalink raw reply
* Re: [PATCH] update-index: add --swap to swap index and worktree content
From: Nguyen Thai Ngoc Duy @ 2011-08-16 14:45 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E4A6A43.7040706@drmicha.warpmail.net>
2011/8/16 Michael J Gruber <git@drmicha.warpmail.net>:
> I had to think about that explanation for a while (partly because "git
> add" does not alter the wt either). So, your patch would support the
> following workflow:
>
> git add foo # have index == wt
> hack foo # change foo in wt
> git update-index --swap foo # add foo and reset to previous state
>
> Am I understanding you right? The option could trickle down to "add".
Well, the point is I want to skip the first phase of normal edit path
(wt -> index -> commit) and edit index directly (even in parts that
are not touched by wt, which means "git add -e" is useless), leaving
my wt "unchanged". Sometimes wt is just too dirty I don't want to make
any more changes to it while I focus on "index -> commit" phase.
I could add an option to fire up editor with a temporary file
containing current index content and automatically update index after
editor is closed. But I'd lose the ability to diff my changes. So I do
need to wt to change index without losing my current wt. I have to
stash my wt somewhere, and index seems a safe place for that.
After swapping, it'd look like index -> wt -> commit, I can do "diff
HEAD" to check index vs head. Once I'm done (and create index'), I can
swap it back to wt -> index' -> commit.
Thinking a bit more, this may have another use case (for lazy guys
like me, anyway). Assume I have separate changes in wt and I'm ready
to make many commit. I should make good commits, which means tests (or
at least a compile to see I don't miss any changes). So I add related
changes to index, then swap wt/index so index becomes wt (and old wt
hidden in index). Test what is to be committed. Good? Swap back,
commit. Repeat with the rest of changes in wt.
My current workflow is picking changes I believe should go together,
commit, then "rebase -i", stopping at each commit to test. It takes
longer (especially when I mis-pick changes).
> I share the pov that "add -p with e" sometimes doesn't cut it. But
> similarly, the fact that "add -p" can't be used to undo a previous "add
> -p" is suboptimal. Both issues could be solved with a 3way stage tool. I
> have this on my todo/wish list, and I seem to recall that Jeff or Junio
> came up with a few lines of (scripting) code for that. That would depend
> on the availability of proper tools, though (e.g. vim in diff mode).
That'd be great.
--
Duy
^ permalink raw reply
* Позвони двери с 50 скидкой 495 номер 740-90-22
From: Aafgd Gennady @ 2010-08-16 16:12 UTC (permalink / raw)
To: git, git
Супер двери
супер не дорого
495 740-90-22
http://u.to/Zn4gAQ
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Jeff King @ 2011-08-16 15:14 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michael Schubert, git
In-Reply-To: <4E4A729D.9030906@drmicha.warpmail.net>
On Tue, Aug 16, 2011 at 03:37:33PM +0200, Michael J Gruber wrote:
> > This isn't right. You are assuming that a remote called "foo" will have
> > all of its branches in refs/remotes/foo. That's true under the default
> > configuration, but technically speaking, the remote tracking branches of
> > "foo" are defined by the right-hand side of foo's fetch refspecs.
>
> You are 100% right here, but...
>
> > So I think you want something more like this:
>
> ...the op still might want to filter simply by the remote name.
That is a perfectly reasonable approach. It just should be called
"--glob" or something, and not "remote". git-tag allows patterns to an
explicit "tag -l", but "-l" is already taken for git-branch.
> Reminds me that I have to resurrect my patterns-with-branches series....
Please do. I think it's a much simpler and more versatile solution to
the same problem.
-Peff
^ permalink raw reply
* GIT commit strategy
From: Vadim K. @ 2011-08-16 16:17 UTC (permalink / raw)
To: git
Hello all,
Imagine developer A has changed files f1 and f2, then made commit and
push to the server
Developer B has changed files f2 and f3 and made local commit.
Next B wants to publish changes to the server and make pull to resolve
conflicts at f2. After pulling from the server it has all 3 files - f1, f2
and f3 to commit before push. But B did not changed f1 and actually can
"ban" this change if he commits only f2 and f3 - files that were changed by
him. In latter case after pushing to the server GIT will restore previous
version of the f1, even if it has more recent one !! It does not seem to be
very logical.
Question: is it possible to show to the developer only files, that he
changes? Like in SVN - after updating from the server developer must resolve
conflicts (if any) and only commits changes that he has made. By the way -
in a case of non-conflicting files (let me say A changes f1, B changes f2)
GIT makes commit automatically and does not show to the B, that f1 was
changed and need to be re-commited. B only need to push the change back.
Thank you,
Vadim.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11) : Guidance for new contributors?
From: Junio C Hamano @ 2011-08-16 16:40 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <AFD36BA266B14DAAA919E1AC1BDF0857@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> Would it it be possible to include a regular link to an explanation
> for new contributors?
After each release from the 'master' branch I try to send out a copy of
http://git-blame.blogspot.com/p/note-from-maintainer.html
to the list, which is meant to be that piece of information.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Junio C Hamano @ 2011-08-16 16:45 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0mxHT8by86-P=Msopgib1ToeHcfwsSXBYBgvN_dm75GnA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
>> [...]
>> Will merge to "next".
>
> If this won't graduate to 'next' before the 24th, I have plenty of
> time to re-roll fixing all the issues that I've addressed in the
> beginning of the new series.
I take it that you mean by "the new series" the 6-patch "Towards a
generalized sequencer" topic?
It is ultimately up-to-you. If you feel the fix-up is against glaring
errors in the earlier round that you would prefer not to see in the
history cast-in-stone, I am perfectly Ok to wait for a re-roll. On the
other hand, if they are mostly cosmetic fixes without major semantic
changes, it may be easier for everybody to see them fixed in-tree.
Your call.
^ permalink raw reply
* Re: GIT commit strategy
From: Michael Witten @ 2011-08-16 16:46 UTC (permalink / raw)
To: Vadim K.; +Cc: git
In-Reply-To: <C0B80A98F4E14FA287D3BAFA8366BEAC@procyon>
2011/8/16 Vadim K. <klug@hot.ee>:
> Hello all,
>
> Imagine developer A has changed files f1 and f2, then made commit and push
> to the server
> Developer B has changed files f2 and f3 and made local commit.
>
> Next B wants to publish changes to the server and make pull to resolve
> conflicts at f2. After pulling from the server it has all 3 files - f1, f2
> and f3 to commit before push. But B did not changed f1 and actually can
> "ban" this change if he commits only f2 and f3 - files that were changed by
> him. In latter case after pushing to the server GIT will restore previous
> version of the f1, even if it has more recent one !! It does not seem to be
> very logical.
>
> Question: is it possible to show to the developer only files, that he
> changes? Like in SVN - after updating from the server developer must resolve
> conflicts (if any) and only commits changes that he has made. By the way -
> in a case of non-conflicting files (let me say A changes f1, B changes f2)
> GIT makes commit automatically and does not show to the B, that f1 was
> changed and need to be re-commited. B only need to push the change back.
It is difficult to understand exactly what you have written here, but
I feel that git already does what you want, so I don't understand why
you are confused.
Please provide a concrete example (with git commands, expected
results, actual results, etc.) so that we can understand each other.
^ permalink raw reply
* Re: [PATCH v3 2/2] Move git-dir for submodules
From: Junio C Hamano @ 2011-08-16 17:34 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git, jens.lehmann, hvoigt
In-Reply-To: <1313178913-25617-3-git-send-email-iveqy@iveqy.com>
Fredrik Gustafsson <iveqy@iveqy.com> writes:
> diff --git a/git-submodule.sh b/git-submodule.sh
> index bc1d3fa..ace6c1d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -122,14 +122,53 @@ module_clone()
> path=$1
> url=$2
> reference="$3"
> + gitdir=
> + gitdir_base=
> + name=$(module_name "$path")
> + if test -z "$name"
> + then
> + name="$path"
> + fi
This conditional is not needed; module_name dies when it cannot find the
name for the path, as it should.
If the defaulting to the path itself were a good idea (which I do not
think it is), that should be done in module_name so that other callers
that tried to find the name for a given path that does not have a named
module would get a consistent result.
^ permalink raw reply
* Re: [PATCH] xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
From: Junio C Hamano @ 2011-08-16 17:39 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Marat Radchenko
In-Reply-To: <20110816113710.000025a7@unknown>
Tay Ray Chuan <rctay89@gmail.com> writes:
> From 0da9ec94604978f877e7f7c00d307b5cdbb22b29 Mon Sep 17 00:00:00 2001
> From: Tay Ray Chuan <rctay89@gmail.com>
> Date: Tue, 16 Aug 2011 11:35:28 +0800
> Subject: [PATCH] xdiff/xprepare: improve O(n*m) performance in
> xdl_cleanup_records()
You do not need these four lines. Thanks.
> In xdl_cleanup_records(), we see O(n*m) performance, where n is the
> number of records from xdf->dstart to xdf->dend, and m is the size of a
> bucket in xdf->rhash (<= by mlim).
>
> Here, we improve this to O(n) by pre-computing nm (in rcrec->len(1|2))
> in xdl_classify_record().
Could we have some benchmarks to let the readers get a feel of how much
improvement this patch brings in?
This tries to trade cycles with memory, right? How much bloat are we
talking about here?
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Junio C Hamano @ 2011-08-16 17:43 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <20110816100949.GA10859@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Is it okay if we install the files into
> $(git --exec-path)/mergetools/ instead?
Surely, and thanks.
It is much better than "$(git --exec-path)/mergetools--$backend" ;-).
^ permalink raw reply
* Re: [PATCH 6/7] sequencer: Expose API to cherry-picking machinery
From: Junio C Hamano @ 2011-08-16 17:51 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110814152204.GJ18466@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Subject: revert: plug memory leak in "cherry-pick root commit" codepath
>
> The empty tree passed as common ancestor to merge_trees() when
> cherry-picking a parentless commit is allocated on the heap and never
> freed.
Thanks for noticing, but shouldn't we be just using
lookup_tree((const unsigned char *)EMPTY_TREE_SHA1_BIN)
or something, instead of hand-crafting a fake tree object?
^ permalink raw reply
* Re: [PATCH] commit: check return value of lookup_commit()
From: Junio C Hamano @ 2011-08-16 18:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8AusStKNWuw3j740r4Nc0FhzR+jJZJNaesxn68pr7dTqA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2011/8/16 Junio C Hamano <gitster@pobox.com>:
>> The change itself looks good to me but a point and a half to think about:
>>
>> - In this if/elseif/.../else cascade, everybody except for the
>> "initial_commit" case needs to make sure that head_sha1 points at a
>> valid commit and get an commit object. Hoisting the scope of the
>> variable "commit" one level in your patch is good, but it would make it
>> easier to read and the future code modification much less error prone
>> if (1) you called lookup_commit() and checked for errors before
>> entering this if/elseif/... cascade, and (2) you renamed this variable
>> to "head_commit".
>
> But then I would need to avoid die()ing in "initial_commit" case.
That's exactly what I said.
if (!initial)
/* we need to know the head_commit */
head_commit = lookup_and_check(HEAD);
/* depending on what kind of commit, we need different stuff */
if (initial)
... going to create a parentless commit
else if (amending)
... use the head_commit to learn parent, reuse the message
... from there
else if ...
These two are independent if/else cascades in the sense that the first is
about learning the details of head_commit, and the latter is about
learning how the commit is done, and in a subset of the latter head_commit
is used.
>> - Whether we like it or not, many people have a broken reimplementations
>> of git that can put a non-commit in HEAD, and they won't be fixed
>> overnight. Instead of erroring out, would it be nicer of us if we just
>> warned, unwrapped the tag and used the tagged commit instead?
>
> How about replacing those lookup_commit() with this? It would tolerate
> tag-in-branch case, but also warn users that something's gone wrong.
Yes, that is exactly what I meant.
Thakns.
^ permalink raw reply
* [PATCH v2] revert: plug memory leak in "cherry-pick root commit" codepath
From: Jonathan Nieder @ 2011-08-16 18:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <7v39h1i6rr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thanks for noticing, but shouldn't we be just using
>
> lookup_tree((const unsigned char *)EMPTY_TREE_SHA1_BIN)
>
> or something, instead of hand-crafting a fake tree object?
Yes. Ever since v1.5.5-rc0~180^2~1 (hard-code the empty tree object,
2008-02-13), there is no need to call pretend_sha1_file() again to
get a fake empty tree object, so this lookup_tree() should work
fine.
-- >8 --
Subject: revert: plug memory leak in "cherry-pick root commit" codepath
For each parentless commit it is asked to reuse, "git cherry-pick" and
"git revert" hand-craft a fake parent tree object on the heap to pass
to merge_trees(). Leaking such a small one-time allocation would not
be a big deal, but now that cherry-pick/revert can take multiple
commit arguments, it can start to add up.
The fix is simple: don't create a new fake empty tree at all, but rely
on the built-in one that has existed since 346245a1 (hard-code the
empty tree object, 2008-02-13).
While at it, add a test to make sure cherry-picking multiple
parentless commits continues to work.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
---
builtin/revert.c | 7 +------
t/t3503-cherry-pick-root.sh | 27 ++++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 853e9e40..a26a7c93 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -273,12 +273,7 @@ static void write_message(struct strbuf *msgbuf, const char *filename)
static struct tree *empty_tree(void)
{
- struct tree *tree = xcalloc(1, sizeof(struct tree));
-
- tree->object.parsed = 1;
- tree->object.type = OBJ_TREE;
- pretend_sha1_file(NULL, 0, OBJ_TREE, tree->object.sha1);
- return tree;
+ return lookup_tree((const unsigned char *)EMPTY_TREE_SHA1_BIN);
}
static NORETURN void die_dirty_index(const char *me)
diff --git a/t/t3503-cherry-pick-root.sh b/t/t3503-cherry-pick-root.sh
index b0faa299..472e5b80 100755
--- a/t/t3503-cherry-pick-root.sh
+++ b/t/t3503-cherry-pick-root.sh
@@ -16,15 +16,40 @@ test_expect_success setup '
echo second > file2 &&
git add file2 &&
test_tick &&
- git commit -m "second"
+ git commit -m "second" &&
+
+ git symbolic-ref HEAD refs/heads/third &&
+ rm .git/index file2 &&
+ echo third > file3 &&
+ git add file3 &&
+ test_tick &&
+ git commit -m "third"
'
test_expect_success 'cherry-pick a root commit' '
+ git checkout second^0 &&
git cherry-pick master &&
test first = $(cat file1)
'
+test_expect_success 'cherry-pick two root commits' '
+
+ echo first >expect.file1 &&
+ echo second >expect.file2 &&
+ echo third >expect.file3 &&
+
+ git checkout second^0 &&
+ git cherry-pick master third &&
+
+ test_cmp expect.file1 file1 &&
+ test_cmp expect.file2 file2 &&
+ test_cmp expect.file3 file3 &&
+ git rev-parse --verify HEAD^^ &&
+ test_must_fail git rev-parse --verify HEAD^^^
+
+'
+
test_done
--
1.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox