headers
Junio C Hamano | 1 Mar 2011 01:11
Picon
Picon
Favicon
Gravatar

Re: git diff: add option for omitting the contents of deletes

Junio C Hamano <gitster <at> pobox.com> writes:

> Jeff King <peff <at> peff.net> writes:
>
>> I'm not quite sure what lossage you mean. On the recipient's end? They
>> can just "git revert", no?

This is beating on a dead horse, but in my previous life, in a project I
wasn't deeply involved in, a deployment procedure used was to:

 - give git-archive tarball of a major release to the target machine that
   does not have git repository, and extract the tarball;

 - maintain 'maint' branch, and show the tip of 'maint' on a test server,
   but give the client vetoing power on individual changes;

 - hence ending up preparing a format-patch output for selected changes,
   and running git-apply on the target machine to update it.

The -M/-C options would have worked well in this scenario, including the
recovery from "oops--that didn't work, please revert asap" (I don't know
if they actually used -M/-C when preparing the incremental updates,
though).  The -D option does not have the same reversibility.

I am (have been) only reacting to the earlier statement by Michael that -D
is the same as -M/-C and reversibility does not matter.  It does in such a
situation.

Now that the project with that deployment procedure is totally behind me,
I probably shouldn't care too much about such a workflow, but I suspect
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Bradley | 1 Mar 2011 01:12
Gravatar

problem with updating a shallow clone via a branch fetch

So I have a git repo that is shallow cloned:

  % git clone --depth 1 <repo url>

Sometimes (very rarely), when I do a branch fetch to update that
repository I get an error:

 % git fetch origin +refs/head/≤branch>:refs/remotes/origin/≤branch>

fatal: did not find object for shallow <hash>

There are only 3 mentions of this error on google, none of which are
enlightening.  The error is being emitted by receive_need(void) in
upload-pack.c.  The commit in question exists in the named branch in
the upstream repository, and I'm not aware that anything sketchy
(forced pushes, etc.) has gone on.  I'm going to continue to research
the history of the repo and the deployment, but I can't seem to get
any insight on what the error actually means (i.e., what conditions
would cause this error to be triggered).

Any help is appreciated,
Rick
Permalink | Reply | 3 comments |
headers
Junio C Hamano | 1 Mar 2011 01:25
Picon
Picon
Favicon
Gravatar

Re: problem with updating a shallow clone via a branch fetch

Rick Bradley <rick <at> rickbradley.com> writes:

> So I have a git repo that is shallow cloned:
>
>   % git clone --depth 1 <repo url>
>
> Sometimes (very rarely), when I do a branch fetch to update that
> repository I get an error:
>
>  % git fetch origin +refs/head/≤branch>:refs/remotes/origin/≤branch>
>
> fatal: did not find object for shallow <hash>

The message comes from the repository you are fetching from.  When you
fetch from a shallow clone, the fetch process on your end tells the other
side what commits your incomplete history ends at, and if the other end
does not have any of these commits, you get that message.  So the only
case (unless there is a bug---and I don't think this codepath is heavily
exercised so it is very possible there are bugs) you would see that
message is if the other side rewound the branch and then later garbage
collection lost the commit.
Permalink | Reply | 2 comments |
headers
Junio C Hamano | 1 Mar 2011 01:41
Picon
Picon
Favicon
Gravatar

Re: [PATCH svn-fe] fast-import: make code "-Wpointer-arith" clean

Jonathan Nieder <jrnieder <at> gmail.com> writes:

> Jonathan Nieder wrote:
>
>> This should fix it, I suppose?
>
> Pushed out.  Thanks again.

Thanks, pulled.
Permalink | Reply | 0 comments |
headers
Jakub Narebski | 1 Mar 2011 02:01
Picon
Gravatar

Re: [PATCH/RFC] gitweb: Restructure projects list generation

On Sun, 27 Feb 2011, Jakub Narebski wrote:
> On Sun, 27 Feb 2011, Jonathan Nieder wrote:
> > Jakub Narebski wrote:

> > > +# this assumes that forks follow immediately forked projects:
> > > +# [ ..., 'repo.git', 'repo/fork.git', ...]; if not, set second
> > > +# parameter to true value to sort projects by path first.
> > > +sub filter_forks_from_projects_list {
> > > +	my ($projects, $need_sorting) =  <at> _;
> > > +
> > > +	 <at> $projects = sort { $a->{'path'} cmp $b->{'path'} }  <at> $projects
> > > +		if ($need_sorting);
> > 
> > What happens in this scenario?
> > 
> > 	git.git
> > 	git.related.project.git
> > 	git/platforms.git
> 
> Thanks for catching this.
> 
> It looks like I have oversimplified the algorithm by requiring that 
> forked project directly precedes any of its forks (if they exists).
> I'd have to redo this part of patch.
> 
> > [...]
> > >  <at>  <at>  -4747,23 +4784,36  <at>  <at>  sub fill_project_list_info {
> > >  		if (!defined $pr->{'owner'}) {
> > >  			$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
> > >  		}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Mar 2011 02:05
Picon
Picon
Favicon
Gravatar

What's cooking in git.git (Feb 2011, #07; Mon, 28)

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.

I started draft release notes for 1.7.5 on 'master' branch.

--------------------------------------------------
[New Topics]

* jc/diff-irreversible-delete (2011-02-28) 1 commit
 - git diff -D: omit the preimage of deletes

Just a POC.

* jc/index-pack (2011-02-25) 5 commits
 - index-pack --verify: read anomalous offsets from v2 idx file
 - write_idx_file: need_large_offset() helper function
 - index-pack: --verify
 - write_idx_file: introduce a struct to hold idx customization options
 - index-pack: group the delta-base array entries also by type

Still a WIP.

* mm/push-default-advice (2011-02-28) 2 commits
 - push: better error messages for detached HEAD and "no destination"
 - push: better error message when push.default = tracking

There were some rewording discussion I didn't roll into this, not because
I had objections to, but because I was handling other topics.  I expect
I'll see a reroll soonish so that we can merge this down soonish.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Elijah Newren | 1 Mar 2011 02:08
Picon

[PATCHv2 0/3] Fix unnecessary (mtime) updates of files during merge

This patch series fixes a bug reported by Stephen Rothwell -- that
during merges git would unnecessarily update modification times of
files.

There are two testcases included in this patch series.  The first is a
simple case to test the originally reported bug; this testcase is
fixed in this series (as is Stephen's original linux-next testcase).
The second testcase suffers from the exact same problem, but arises
from a different situation and is not fixed in this series.  That
testcase is slightly harder to solve because:

  * unpack_trees + threeway_merge throws away the original index entry
    with stat information when it notices the directory/file conflict

  * make_room_for_directories_of_df_conflicts() must remove such files
    from the working copy or the corresponding directory and files
    below it will be unable to be written to the working copy (which
    can cause spurious conflicts, or make resolving conflicts very
    hard for users who don't know how to access the many files missing
    from their working copy).

We could fix this second testcase by recording stat information for
files removed by make_room_for_directories_of_df_conflicts(), and
then, if those files are reinstated at the end of conflict resolution
(i.e. the directory of the D/F conflict went away during the merge),
then call utime() to reset the modification times on those files back
to what they originally were.

(Technically, the second testcase that I left unfixed is not a
regression; prior versions of git would fail the merge and record the
(Continue reading)

Permalink | Reply | 13 comments |
headers
Elijah Newren | 1 Mar 2011 02:08
Picon

[PATCHv2 1/3] t6022: New test checking for unnecessary updates of renamed+modified files


Signed-off-by: Elijah Newren <newren <at> gmail.com>
---
 t/t6022-merge-rename.sh |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 1ed259d..3667e18 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
 <at>  <at>  -609,4 +609,36  <at>  <at>  test_expect_success 'check handling of differently renamed file with D/F conflic
 	! test -f original
 '

+test_expect_success 'setup avoid unnecessary update, normal rename' '
+	git reset --hard &&
+	git checkout --orphan avoid-unnecessary-update-1 &&
+	git rm -rf . &&
+	git clean -fdqx &&
+
+	printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >original &&
+	git add -A &&
+	git commit -m "Common commmit" &&
+
+	git mv original rename &&
+	echo 11 >>rename &&
+	git add -u &&
+	git commit -m "Renamed and modified" &&
+
+	git checkout -b merge-branch-1 HEAD~1 &&
(Continue reading)

Permalink | Reply | 3 comments |
headers
Elijah Newren | 1 Mar 2011 02:08
Picon

[PATCHv2 2/3] t6022: New test checking for unnecessary updates of files in D/F conflicts

Reported-by: Stephen Rothwell <sfr <at> canb.auug.org.au>
Signed-off-by: Elijah Newren <newren <at> gmail.com>
---
 t/t6022-merge-rename.sh |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 3667e18..a5d252b 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
 <at>  <at>  -641,4 +641,40  <at>  <at>  test_expect_failure 'avoid unnecessary update, normal rename' '
 	git diff-files --exit-code # Is "rename" clean, or only racily clean?
 '

+test_expect_success 'setup avoid unnecessary update, with D/F conflict' '
+	git reset --hard &&
+	git checkout --orphan avoid-unnecessary-update-2 &&
+	git rm -rf . &&
+	git clean -fdqx &&
+
+	mkdir df &&
+	printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" >df/file &&
+	git add -A &&
+	git commit -m "Common commmit" &&
+
+	git mv df/file temp &&
+	rm -rf df &&
+	git mv temp df &&
+	echo 11 >>df &&
+	git add -u &&
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elijah Newren | 1 Mar 2011 02:08
Picon

[PATCHv2 3/3] merge-recursive: When we detect we can skip an update, actually skip it

In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20),
there was code that checked for whether we could skip updating a file in
the working directory, based on whether the merged version matched the
current working copy.  Due to the desire to handle directory/file conflicts
that were resolvable, that commit deferred content merging by first
updating the index with the unmerged entries and then moving the actual
merging (along with the skip-the-content-update check) to another function
that ran later in the merge process.  As part moving the content merging
code, a bug was introduced such that although the message about skipping
the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently
high), the file would be unconditionally updated in the working copy
anyway.

When we detect that the file does not need to be updated in the working
copy, update the index appropriately and then return early before updating
the working copy.

Signed-off-by: Elijah Newren <newren <at> gmail.com>
---
 merge-recursive.c       |   17 +++++++++++------
 t/t6022-merge-rename.sh |    2 +-
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 16c2dbe..ec07a30 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
 <at>  <at>  -354,10 +354,11  <at>  <at>  static void make_room_for_directories_of_df_conflicts(struct merge_options *o,
 	 * make room for the corresponding directory.  Such paths will
 	 * later be processed in process_df_entry() at the end.  If
(Continue reading)

Permalink | Reply | 3 comments |

Gmane