* Re: Planned new release of git
From: Junio C Hamano @ 2006-11-07 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611071504200.3667@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 7 Nov 2006, Jakub Narebski wrote:
>>
>> Do I understand correctly that the work on not exploding downloaded
>> pack on fetch, but making it non-thin, and related work on archival
>> packs (not to be considered for repacking) is not considered ready
>> (and tested)?
>
> I'd like to see a new version with both the packed refs and the
> non-exploading download on by default. Maybe time for a git-1.5.0 release
> from master?
Don't worry, packed refs is already part of 'master' so whatever
the next feature release is called it will be part of it ;-).
^ permalink raw reply
* Re: [PATCH] Return non-zero status from pull if merge fails.
From: Junio C Hamano @ 2006-11-08 0:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061107181053.GA26856@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> diff --git a/git-merge.sh b/git-merge.sh
> index cb09438..7725908 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -203,7 +203,7 @@ f,*)
> git-update-index --refresh 2>/dev/null
> new_head=$(git-rev-parse --verify "$1^0") &&
> git-read-tree -u -v -m $head "$new_head" &&
> - finish "$new_head" "Fast forward"
> + finish "$new_head" "Fast forward" || exit 1
> dropsave
> exit 0
> ;;
The shell function "finish" itself exits when there is an error;
is this needed?
> @@ -214,7 +214,7 @@ f,*)
> + git var GIT_COMMITTER_IDENT >/dev/null || exit 1
> @@ -225,7 +225,7 @@ f,*)
> + ) || exit 1
> @@ -253,7 +253,7 @@ f,*)
> +git var GIT_COMMITTER_IDENT >/dev/null || exit 1
> @@ -327,7 +327,7 @@ done
> + result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit 1
Are these needed? Wouldn't "something || exit" already exit non-zero
when something exits non-zero?
> diff --git a/git-pull.sh b/git-pull.sh
> index ed04e7d..d10fcdd 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -102,6 +102,6 @@ case "$strategy_args" in
> esac
>
> merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
> -git-merge "--reflog-action=pull $*" \
> +exec git-merge "--reflog-action=pull $*" \
> $no_summary $no_commit $squash $strategy_args \
> "$merge_name" HEAD $merge_head
I think this is a good change.
^ permalink raw reply
* Re: gitk feature request..
From: Pierre Dumuid @ 2006-11-08 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vslgu28do.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
> Having said that, is the gitk view supposed to be shared across
> users of a single repository?
>
> If you imagine yourself logging into kernel.org (perhaps X
> forwarded over ssh to your local machine) and browsing
> /pub/scm/git/git.git/, the repository itself would not be
> writable by you. Even if it were, I do not think you would want
> me to reuse the view you used from there next time I did the
> same on the same repository.
>
I've mainly been thinking about users at a home who clone / update a
remote repository and work in that repository for themselves. The idea
of sshing into another machine seems to me not how git is designed to be
used..
Also when one clones, I thought it cloned only the git repository, and
not the files for the porcelaines. (an example being the branches directory)
> It might make sense to give --state=dir/ parameter to gitk and
> tell it to use that directory to keep persistent data. Also I
> seem to recall you already have one file under $HOME/ to make
> window geometry or something persistent.
>
I use gitk a lot, and I'd rather not have to specify a command line
option all the time, but an override from using the settings in the
another directory would be fine..
[-- Attachment #2: pierre.dumuid.vcf --]
[-- Type: text/x-vcard, Size: 385 bytes --]
begin:vcard
fn:Pierre Dumuid
n:Dumuid;Pierre
org:The University of Adelaide;Mechanical Engineering
adr:;;;Adelaide;South Australia;5005;Australia
email;internet:pierre.dumuid@adelaide.edu.au
title:Postgraduate Student
tel;work:8303 3847
tel;home:8388 5727
tel;cell:0407570263
note:CRICOS Provider Number 00123M
x-mozilla-html:TRUE
url:http://www.adelaide.edu.au
version:2.1
end:vcard
^ permalink raw reply
* What's the meaning of `parenthood' in git commits?
From: Nix @ 2006-11-08 0:39 UTC (permalink / raw)
To: git
So I'm back on the weird porcelain I mentioned months and months ago,
the one which treats source trees as named collections of patches merged
together in different ways, almost like stgit on steroids, only not.
It occurred to me recently that packed refs provide about 50% of what I
need (efficient handling of lots and lots of refs); most of the other
50% consits of a new extremely weird git merge strategy,
`git-merge-patched', which merges branches A and B by finding the most
recent merge-base between branch B and any branch listed in
.git/refs/trunks (`trunks' being a directory holding heads which are
treated this way by this weird merge strategy; the porcelain will have
to keep it up to date, which shouldn't be too terribly hard), and
patch(1)ing the diff between that base and the tip of branch B into
branch A. (A patch rejection, of course, means merge-by-hand and commit,
as usual with merge conflicts.)
The idea being that if you have a tree like this:
B
------------- ref trunks/latest
\
------ ref heads/some-change-foo
... -------- ref trunks/old-and-grotty
then this merge strategy, when asked to merge heads/some-change-foo into
trunks/old-and-grotty would spot that point B was the most recent
merge point into anything in trunks/, generate a diff between point B
and heads/some-change-foo, and patch it into trunks/old-and-grotty.
(I *know* this is really weird, but I've got a choice of doing this or
continuing to use SCCS with the world's most horrible shell script
wrapper as the source code repository for ~5Gb of source, with tens of
thousands of files in a flat directory structure, expanded to 50Gb
because we're storing binary files in there by the astonishingly
inefficient means of uuencoding them and sccsing the result: you may be
sick now. I know which I'd prefer. I may be distorting git into
something unrecognisable to its own father but it's that or I go insane
*and* run out of disk space.)
After all that setup, my question's simple. Does a `parent' in git
terminology simply mean `this commit was derived in some way from the
commit listed here'? If so, I suppose I can list heads/some-change-foo
as one parent on these merge commits, even though the `merging'
mechanism is so odd that I expect to be pelted with rotten vegetables as
soon as I post this.
But it's that or SCCS.
(Of course this will go into a public git repository for people to laugh
at. I don't expect anyone to actually *use* it.)
--
Rich industrial heritage: lifeless wasteland. `The land
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Jakub Narebski @ 2006-11-08 0:52 UTC (permalink / raw)
To: git
In-Reply-To: <878ximbwm3.fsf@hades.wkstn.nix>
Nix wrote:
> After all that setup, my question's simple. Does a `parent' in git
> terminology simply mean `this commit was derived in some way from the
> commit listed here'? If so, I suppose I can list heads/some-change-foo
> as one parent on these merge commits, even though the `merging'
> mechanism is so odd that I expect to be pelted with rotten vegetables as
> soon as I post this.
Yes, being parent means that this commit was derived in some way from the
commit listed here. It needs not to be this commit is the result of merge
of commits listed here... there was a discussion some time ago to use one
of parents (first for example) instead of special header for "prev" link to
previous value of the ref (which discussion was obsoleted by reflog).
It provies two things you have to think about if to use 'parenthood' for
something a bit unexpected. First, parents are connectivity, so even if you
delete trunks/some-name and then prune, averything that was merged in some
branch or tag which lives still wouldn't get pruned. Second, the
information about merges is used in merge strategies: consider if having
this information would help your strange merge strategy.
And of course there is a question if the graph as visualized by for example
gitk would have more sense or not with the "strange merges" marked as
merges.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Linus Torvalds @ 2006-11-08 0:58 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <878ximbwm3.fsf@hades.wkstn.nix>
On Wed, 8 Nov 2006, Nix wrote:
>
> [ Nix explains what he's doing now with SCCS ]: you may be
> sick now.
Wow. You've got some strange setup there, Nix.
> After all that setup, my question's simple. Does a `parent' in git
> terminology simply mean `this commit was derived in some way from the
> commit listed here'?
Well, strictly speaking, git doesn't itself assign much any real meaning
to "parent" at all. It has the obvious meanings:
- the parent pointers act as reachability graph edges (so fsck cares
about it a lot, of course)
- listing the "log" of a commit will show everything reachable from that
commit and it's parents, of course (with the commit date-stamp being
used as a "ordering" when having multiple choices of commits to show)
- it has the obvious meanings for the "revision arithmetic", ie revision
name parsing (ie "commit~3^2")
- parenthood will be used to show the diff ("git show", "git log -p" and
friends)
- the "merge-base" algorithms obviously use it to find the most recent
common ancestor, and that in turn impacts the normal merge strategies,
of course.
so parenthood does obviously have a number of very specific technical
meanings for different programs, but at the same time, no, git doesn't
really "care". You can happily generate your own parenthood if you want
to, and git will just continue to follow the above rules.
> If so, I suppose I can list heads/some-change-foo as one parent on these
> merge commits, even though the `merging' mechanism is so odd that I
> expect to be pelted with rotten vegetables as soon as I post this.
Yeah, git won't care. If you screw up parenthood, you have a few problems:
- the diffs may look really strange. In particular, if you list multiple
parents, the git "diff" functions will all just assume that it's a
merge, and a "git show" will start showing the combined diff (which is
usually empty).
So if you end up having multiple parents, not because it was "really" a
merge, but because you use the other parent pointer to point to some
"source" for the patch, things like "git log -p" won't give nice output
any more. You need to manually ask for the diff with something like
# show diff from second parent
git diff commit^2..commit
instead.
- listing too _few_ parents is potentially more serious, if you have
reachability issues (ie you wanted to keep the other source around, but
since you didn't list it as a parent, git won't know that it had
anything to do with your commit, so it may be pruned away unless you
have some other way to reach it)
but if you just have a really strange merge algorithm, and the _data_
associated with the parents is "surprising" from the standpoint of the
default merge, git really won't care at all.
Your usage does sound a bit strange.
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Junio C Hamano @ 2006-11-08 1:13 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <878ximbwm3.fsf@hades.wkstn.nix>
Nix <nix@esperi.org.uk> writes:
> The idea being that if you have a tree like this:
>
> B
> ------------- ref trunks/latest
> \
> ------ ref heads/some-change-foo
>
> ... -------- ref trunks/old-and-grotty
>
>
> then this merge strategy, when asked to merge heads/some-change-foo into
> trunks/old-and-grotty would spot that point B was the most recent
> merge point into anything in trunks/, generate a diff between point B
> and heads/some-change-foo, and patch it into trunks/old-and-grotty.
This is a standard "cherry-picking" practice.
> After all that setup, my question's simple. Does a `parent' in git
> terminology simply mean `this commit was derived in some way from the
> commit listed here'?
When you think about commit ancestry, think of it this way:
These commits I list as its parents of this new commit, and
everything that leads to them, are what I considered when
derived this commit. This new child commit of them suits the
purpose of _my_ branch better than any of these parent
commits I took into consideration because of such and such
reasons that I stated in its commit log message.
If you mark the resulting commit on old-and-grotty to have
some-change-foo as one of its parents, because some-change-foo
has almost everything 'latest' has (up to point B), you are also
saying "I have considered everything that happened between
old-and-grotty and B when making this commit".
What's implied by that statement is this, even though you do not
explicitly say:
I reject everything that happened on the development line
that led to 'latest' up to point B since old-and-grotty was
forked.
This is not necessarily a bad thing, by the way. For somebody
who is trying to maintain extremely-stable branch by cherry
picking only changes in a few narrow areas from the mainline
would _want_ to leave most of the "new good stuff" out from his
branch. That's why I emphasized _my_ a few paragraphs above.
But it is _so_ different from the mindset of usual "every branch
makes progress _forward_ perhaps with different pace". In this
example, this branch is actively choosing to stay behind and
refusing to take changes from the 'latest'. So your users need
to really understand what they are doing. For example, if there
is another topic forked off of B (or at a later commit from
there that leads to 'latest'), after your "funny merge" took
place, even the usual merge strategies would work as expected by
you --- it would still ignore the changes up to B because you
told git to do so.
Also, if you make a good change on top of the resulting merge
that _should_ be applicable to some-change-foo which is based on
the 'latest', you cannot merge that back in the usual way.
Usual git merge will find your first "funny merge" as the merge
base, and because it chooses to reject everything leading to B,
the merge result would look very similar to the set of changes
based on old-and-grotty. Actually, that would even fast forward
to the version you made into a phony "merge" out of the
cherry-picked result.
But that is at least consistent with the statement you made when
you created that commit. Staying behind at old-and-grotty
suited _your_ branch'es purpose better than being based on
'latest'. And a person who is merging _your_ branch into
some-change-foo, by choosing to merge that branch into the
latter, is choosing to share your branch'es purpose, so it is
natural a lot of the "good things" that happened up to B is
rewound by that merge.
So I think as long as you and your users understand what is
going on, I do not see a problem at either the mechanical level
or the philosophical level. But I am sure it would confuse a
lot of people, so please do not come back complaining that you
ended up getting your users heads explode ;-).
^ permalink raw reply
* Re: [PATCH] remove an unneeded test
From: Jeff King @ 2006-11-08 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tero Roponen
In-Reply-To: <Pine.LNX.4.64.0611071239560.18014@jalava.cc.jyu.fi>
On Tue, Nov 07, 2006 at 12:44:33PM +0200, Tero Roponen wrote:
> In wt-status.c there is a test which does nothing.
> This patch removes it.
Junio, please apply. This is leftover from an edit; there's no missing
statement which is supposed to go there.
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Nix @ 2006-11-08 1:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611071644430.3667@g5.osdl.org>
On 8 Nov 2006, Linus Torvalds uttered the following:
> On Wed, 8 Nov 2006, Nix wrote:
>>
>> [ Nix explains what he's doing now with SCCS ]: you may be
>> sick now.
>
> Wow. You've got some strange setup there, Nix.
It's what happens when a version-control system gets implemented as
an emergency hack when moving from VMS, by people who don't really
grok Unix shell scripting... and then you let fifteen years pass,
and nobody dares touch the hack because it's so damned delicate.
It took months of agony to implement crude half-functional branching
in this. Writing a git porcelain should be vastly simpler, even with
the overhead of a conversion tool as well.
Writing that conversion tool will be fun :( e.g. I'm going to have to
identify branches by diffing/xdeltaing each version of a file with every
single previous version of that file, and if the diff is smallest
against a version other than the immediate ancestor, it's assumed to be
a branch against that version. (I'm going to have to fake up packed refs
for these tiny branches so that they're at least accessible in
emergencies, gah.)
It's all, well, nasty. But all will be so much happier in the shining
world of git.
>> After all that setup, my question's simple. Does a `parent' in git
>> terminology simply mean `this commit was derived in some way from the
>> commit listed here'?
>
> Well, strictly speaking, git doesn't itself assign much any real meaning
> to "parent" at all. It has the obvious meanings:
Oh *good*, that's what I thought.
[snip more things which match my understanding]
> - parenthood will be used to show the diff ("git show", "git log -p" and
> friends)
I'll list the patch-merged parent as the second parent, so that you'll only
get the mostly-useless huge diff from that if you actually ask for it, and
will get a more useful result with ^.
> - the "merge-base" algorithms obviously use it to find the most recent
> common ancestor, and that in turn impacts the normal merge strategies,
> of course.
Hm, yeah, if merging iterates down patch-merged branches it might have
interesting consequences, because the trees on one side of patch- merges
are likely to be very different to trees on the other side (years of
development separate them). I'd like a way to specify that those parents
are *not* to be traversed by the merge-base algorithms, really.
A series of
not-merge-base: <sha1 id>
headers, perhaps? (I think that's likely to involve much less code churn
than introducing a new `not-merge-base-parent' tag).
> Yeah, git won't care. If you screw up parenthood, you have a few problems:
>
> - the diffs may look really strange. In particular, if you list multiple
> parents, the git "diff" functions will all just assume that it's a
> merge, and a "git show" will start showing the combined diff (which is
> usually empty).
It is a merge, so that's right. It's just a rather odd merge.
(I don't envisage actual *changes* being made in these commits except to
resolve conflicts.)
> So if you end up having multiple parents, not because it was "really" a
> merge, but because you use the other parent pointer to point to some
> "source" for the patch, things like "git log -p" won't give nice output
> any more. You need to manually ask for the diff with something like
Well, I was envisaging that the other parent pointer would point to the
tip of the changes tree. Going back to that graph again:
B
------------- ref trunks/latest
\
------ ref heads/some-change-foo
... -------- ref trunks/old-and-grotty
The idea is that the patch-merge of trunks/old-and-grotty and
heads/some-change-foo would consist textually of the diff between B and
heads/some-change-foo, applied to trunks/old-and-grotty, and would list
as its parents trunks/old-and-grotty, *and heads/some-change-foo*.
(Perhaps this isn't really a merge after all? Should merge parents be
treated as differently as this? It'll all be covered over by the
porcelain in any case: it won't be possible to confuse a trunk/ with a
normal head and accidentally patch-merge in the wrong direction.)
> - listing too _few_ parents is potentially more serious, if you have
> reachability issues (ie you wanted to keep the other source around, but
> since you didn't list it as a parent, git won't know that it had
> anything to do with your commit, so it may be pruned away unless you
> have some other way to reach it)
Yeah, that would be bad.
> but if you just have a really strange merge algorithm, and the _data_
> associated with the parents is "surprising" from the standpoint of the
> default merge, git really won't care at all.
Good.
> Your usage does sound a bit strange.
Agreed. But there are hundreds of people banging on my door asking for a
proper version control system, quilt isn't a proper version control
system in that sense, and stgit has... issues when you try to distribute
it and when you have a lot of people working on one tree at once: plus
it doesn't fit our weird workflow with multiple parallel release
branches, at least one active development trunk, and all changes done
under a carefully-controlled bug tracking system (it's as if *every*
change has a bugzilla ticket associated, *always*, and we expect to be
able to get from ticket to change efficiently).
(We do both distribution and working-copy-sharing: the trees are too
large to have one tree per person, not least because each tree requires
an entire Oracle instance of its own to play with and massive amounts of
memory; and we have geographically distributed sites with trees of their
own.)
--
Rich industrial heritage: lifeless wasteland. `The land
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Nix @ 2006-11-08 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7qmyc46.fsf@assigned-by-dhcp.cox.net>
On 8 Nov 2006, Junio C. Hamano spake thusly:
> Nix <nix@esperi.org.uk> writes:
>
>> The idea being that if you have a tree like this:
>>
>> B
>> ------------- ref trunks/latest
>> \
>> ------ ref heads/some-change-foo
>>
>> ... -------- ref trunks/old-and-grotty
>>
>>
>> then this merge strategy, when asked to merge heads/some-change-foo into
>> trunks/old-and-grotty would spot that point B was the most recent
>> merge point into anything in trunks/, generate a diff between point B
>> and heads/some-change-foo, and patch it into trunks/old-and-grotty.
>
> This is a standard "cherry-picking" practice.
Yes, pretty much, except that we do *everything* by cherry-picking, and
we want to track the cherry-picks in the same way that all other changes
are tracked (i.e., a small branch for each (numbered) change, patching
madly in all directions into a variety of trunks and release branches,
with all those patches tracked.)
> These commits I list as its parents of this new commit, and
> everything that leads to them, are what I considered when
> derived this commit. This new child commit of them suits the
> purpose of _my_ branch better than any of these parent
> commits I took into consideration because of such and such
> reasons that I stated in its commit log message.
>
> If you mark the resulting commit on old-and-grotty to have
> some-change-foo as one of its parents, because some-change-foo
> has almost everything 'latest' has (up to point B), you are also
> saying "I have considered everything that happened between
> old-and-grotty and B when making this commit".
Yeah. This is the merge-base tracking that Linus mentioned, and it's not
quite what I'm looking for :/ it's a sort of step-parent, really...
> What's implied by that statement is this, even though you do not
> explicitly say:
>
> I reject everything that happened on the development line
> that led to 'latest' up to point B since old-and-grotty was
> forked.
(which is not necessarily true: we might want to backport an earlier
change, also on another `small change branch', later on. Stuff on the
trunks themselves will never want to get backported, but if the
merge-base algorithm traverses patch-merge parent links, it might
consider that a `small change branch' has been merged when it actually
hasn't.)
> This is not necessarily a bad thing, by the way. For somebody
> who is trying to maintain extremely-stable branch by cherry
> picking only changes in a few narrow areas from the mainline
> would _want_ to leave most of the "new good stuff" out from his
> branch. That's why I emphasized _my_ a few paragraphs above.
That's exactly what we're doing, across-the-board.
> But it is _so_ different from the mindset of usual "every branch
> makes progress _forward_ perhaps with different pace". In this
> example, this branch is actively choosing to stay behind and
> refusing to take changes from the 'latest'. So your users need
> to really understand what they are doing.
*hahahaaaaa*... hang on, that *was* a joke, right? ;)
> So I think as long as you and your users understand what is
> going on, I do not see a problem at either the mechanical level
> or the philosophical level. But I am sure it would confuse a
> lot of people, so please do not come back complaining that you
> ended up getting your users heads explode ;-).
OK, I think I need to find a way to notate in the patch-merged commit
that one or more parents should be disregarded when searching for merge
bases (and *only* when searching for merge bases). I think that will
do what's wanted in all areas: i.e., it'll act like a cherry-pick
that shows up in the logs/revlist and so on, but doesn't affect the
semantics of later merges of stuff from anywhere except for the
same limited branch.
(obviously trying to patch-merge B to A twice is always going to
fail, whether or not merge-base traversal jumps into B: I don't
think there's any real need to protect against that.)
--
Rich industrial heritage: lifeless wasteland. `The land
^ permalink raw reply
* Re: What's the meaning of `parenthood' in git commits?
From: Nix @ 2006-11-08 3:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <874ptabubr.fsf@hades.wkstn.nix>
On 8 Nov 2006, nix@esperi.org.uk spake thusly:
> On 8 Nov 2006, Linus Torvalds uttered the following:
>> - the "merge-base" algorithms obviously use it to find the most recent
>> common ancestor, and that in turn impacts the normal merge strategies,
>> of course.
>
> Hm, yeah, if merging iterates down patch-merged branches it might have
> interesting consequences, because the trees on one side of patch- merges
> are likely to be very different to trees on the other side (years of
> development separate them). I'd like a way to specify that those parents
> are *not* to be traversed by the merge-base algorithms, really.
>
> A series of
>
> not-merge-base: <sha1 id>
>
> headers, perhaps? (I think that's likely to involve much less code churn
> than introducing a new `not-merge-base-parent' tag).
Wrong. Sort of.
When doing normal merges you don't want to consider patch-merged parents
as real merges: but there is one situation when you *do* want merge-base
checking to traverse such links.
Say you have the tree just described:
B
------------- ref trunks/latest
\
------ ref heads/some-change-foo
... -------- ref trunks/old-and-grotty
and you want to patch-merge heads/some-change-foo with
trunks/old-and-grotty.
It doesn't quite apply, so you end up with a conflict-resolution. This
will normally be in the merge commit, but there's no guarantee of that:
perhaps you knew the source tree would conflict in advance and fixed it
up so that it wouldn't, leaving the old heads/some-change-foo pointing
before that fixup:
B
------------- ref trunks/latest
\
------- ref heads/some-change-foo
D \
c
|
... -------------- ref trunks/old-and-grotty
Later on, you find a bug in that change. It's still the same conceptual
change, so you fix it, and you want to patch-merge the fix across:
B
------------- ref trunks/latest
\
-----------\ ref heads/some-change-foo
C \ .
c . (link under construction)
| .
... -------------- ref trunks/old-and-grotty
E F
What patch-merge must do in order to produce a diff-merge at point F is
therefore rather more involved than I'd hoped:
- determine B as above (most recent merge-base of heads/some-change-foo
with anything in trunks/).
- determine the merge-base of trunks/old-and-grotty with
heads/some-change-foo, *traversing patch-merge parents*. Call this
base C. (This is the only circumstance in which merge-base
determination should traverse patch-merged parents.)
- Iff that base C is topologically a child of B, then we have already
merged part of this change in the past. In that case, instead of the
merge consisting of the diff between B and F, it consists of the diff
between C and the head, minus the set of changes c. So it remains to
determine c.
- scan backwards along F with git-rev-list, searching specifically for
the most recent patch-merge naming any commit which has C as a
transitive parent: that is point E. (Such a point must exist as long
as only patch-merges have been used to merge heads/some-change-foo
with trunks/old-and-grotty: if other sorts of merge have been used,
all bets are off and I think we can legitimately fail the merge.)
(This requires the ability to distinguish patch-merges from normal
merges, but that's easy if we have any tag at all to distinguish
them, which we must for merge- base traversal to avoid such parents
normally.)
- Reverse out the diff between C and E (if the two are not the same
commit) and remember it temporarily as c.
- Apply the forwards diff between point C and heads/some-change-foo,
and then apply c in the forwards direction (if c is already present,
this is not an error: it just means that whatever conflict-
resolution was necessary as a one-off was later needed on the change
trunk).
I think that should cope with just about everything. I've tried to mock
up all sorts of contrived trees and I can't find anything that doesn't
reduce to that case or a simplification of it. (And no, this case is not
contrived: we test on trunks, so we deal with it whenever anything fails
testing and has to be fixed...)
(Now all I have to do is write it... enough words, time for action.
Actually time for sleep, it's three in the morning here. Action
tomorrow.)
--
Rich industrial heritage: lifeless wasteland. `The land
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-11-08 3:21 UTC (permalink / raw)
To: git
Executive Summary.
[maint]
I might do a 1.4.3.5 with the accumulated stuff, but the
stablization cycle for v1.4.4 has started tonight, so it may
not be worth the effort, unless something more pressing comes
along.
[master]
Three topics that have been cooking in 'next' have been
merged, I've tagged the tip as v1.4.4-rc1.
- Nico and Shawn's keep-pack work;
- Loosening of bogusly overstrict 'a working tree file will
be overwritten by the merge' check;
- git-pickaxe.
[next]
This now is almost empty, and I'd like to keep it that way
until v1.4.5 final. IOW, I'd be happier if people sent in
only obviously correct fixes to 'master' than seeing the next
greatest feature ;-).
By the way, do people mind if I start to rewind and rebase
'next' after every feature release (i.e. tagged release is
made after 'master')? I do not feel a strong need for it, and
'git log --no-merges master..next' will show emptiness
eventually, but being able to restart from clean slate after a
release would be somewhat nice.
[pu]
Johannes's shallow clone work now should rebase cleanly on top
of 'master' although I haven't done so yet. As he said
himself the series is waiting for people who have needs for
such a feature to raise hands.
The part #2 of git-diff/git-apply change has a slight backward
compatibility issue, and until everybody who is affected is
upgraded to v1.4.3 (which has already prepared us for this
change) we cannot push it out to 'master'. It adjusts the
diff output header for files with SP in their names to what
GNU patch accepts.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
merge-recursive implicitely depends on trust_executable_bit
Andy Parkins (2):
Minor grammar fixes for git-diff-index.txt
git-clone documentation didn't mention --origin as equivalent of -o
Jakub Narebski (1):
Documentation: Transplanting branch with git-rebase --onto
Jeff King (1):
Fix git-runstatus for repositories containing a file named HEAD
Johannes Schindelin (1):
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Junio C Hamano (2):
apply: handle "traditional" creation/deletion diff correctly.
adjust_shared_perm: chmod() only when needed.
Shawn O. Pearce (3):
Use ULONG_MAX rather than implicit cast of -1.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Remove unsupported C99 style struct initializers in git-archive.
Tero Roponen (1):
remove an unneeded test
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
merge-recursive implicitely depends on trust_executable_bit
Alexandre Julliard (5):
pack-refs: Store the full name of the ref even when packing only tags.
git.el: Added functions for moving to the next/prev unmerged file.
git.el: Added a function to open the current file in another window.
git.el: Move point after the log message header when entering log-edit mode.
git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.
Andy Parkins (3):
Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
Minor grammar fixes for git-diff-index.txt
git-clone documentation didn't mention --origin as equivalent of -o
Aneesh Kumar K.V (1):
gitweb: Remove extra "/" in path names for git_get_project_list
Eric Wong (2):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
Jakub Narebski (4):
gitweb: Use git-for-each-ref to generate list of heads and/or tags
gitweb: Output also empty patches in "commitdiff" view
gitweb: Better support for non-CSS aware web browsers
Documentation: Transplanting branch with git-rebase --onto
Jeff King (2):
git-pickaxe: work properly in a subdirectory.
Fix git-runstatus for repositories containing a file named HEAD
Johannes Schindelin (1):
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Junio C Hamano (40):
git-pickaxe: blame rewritten.
git-pickaxe -M: blame line movements within a file.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: pagenate output by default.
git-pickaxe: fix nth_line()
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
git-pickaxe: do not keep commit buffer.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: swap comparison loop used for -C
merge: loosen overcautious "working file will be lost" check.
merge-recursive: use abbreviated commit object name.
merge-recursive: make a few functions static.
merge-recursive: adjust to loosened "working file clobbered" check
t6022: ignoring untracked files by merge-recursive when they do not matter
send-pack --keep: do not explode into loose objects on the receiving end.
git-pickaxe: WIP to refcount origin structure.
git-pickaxe: allow -Ln,m as well as -L n,m
git-pickaxe: refcount origin correctly in find_copy_in_parent()
git-pickaxe: tighten sanity checks.
Revert "send-pack --keep: do not explode into loose objects on the receiving end."
git-pickaxe: split find_origin() into find_rename() and find_origin().
git-pickaxe: cache one already found path per commit.
Introduce a new revision set operator <rev>^!
for-each-ref: "creator" and "creatordate" fields
apply: handle "traditional" creation/deletion diff correctly.
git-pickaxe: rename detection optimization
git-pickaxe: simplify Octopus merges further
git-pickaxe: re-scan the blob after making progress with -M
git-pickaxe: re-scan the blob after making progress with -C
git-pickaxe: fix origin refcounting
cherry is built-in, do not ship git-cherry.sh
git-blame: add internal statistics to count read blobs.
git-pickaxe: optimize by avoiding repeated read_sha1_file().
adjust_shared_perm: chmod() only when needed.
Document git-pack-refs and link it to git(7).
git-pickaxe: -L /regexp/,/regexp/
git-pickaxe: allow "-L <something>,+N"
GIT 1.4.3-rc1
Linus Torvalds (2):
Allow '-' in config variable names
git push: add verbose flag and allow overriding of default target repository
Nicolas Pitre (14):
enable index-pack streaming capability
make index-pack able to complete thin packs.
add progress status to index-pack
mimic unpack-objects when --stdin is used with index-pack
enhance clone and fetch -k experience
index-pack: minor fixes to comment and function name
missing small substitution
make git-push a bit more verbose
Allow pack header preprocessing before unpack-objects/index-pack.
git-fetch can use both --thin and --keep with fetch-pack now
improve fetch-pack's handling of kept packs
have index-pack create .keep file more carefully
remove .keep pack lock files when done with refs update
git-pack-objects progress flag documentation and cleanup
Petr Baudis (1):
gitweb: Support for 'forks'
Sean Estabrooks (1):
Add --global option to git-repo-config.
Shawn O. Pearce (11):
Added completion support for git-branch.exe.
Added bash completion support for git-reset.
Use ULONG_MAX rather than implicit cast of -1.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Remove unsupported C99 style struct initializers in git-archive.
Added missing completions for show-branch and merge-base.
Only load .exe suffix'd completions on Cygwin.
Bash completion support for remotes in .git/config.
Take --git-dir into consideration during bash completion.
Support bash completion on symmetric difference operator.
Remove more sed invocations from within bash completion.
Shawn Pearce (5):
Allow short pack names to git-pack-objects --unpacked=.
Only repack active packs by skipping over kept packs.
Teach git-index-pack how to keep a pack file.
Remove unused variable in receive-pack.
Teach receive-pack how to keep pack files based on object count.
Tero Roponen (1):
remove an unneeded test
* The 'next' branch, in addition, has these.
Junio C Hamano:
upload-pack: stop the other side when they have more roots than we do.
* The 'pu' branch, in addition, has these.
Johannes Schindelin (6):
Build in shortlog
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
Junio C Hamano (6):
git-branch -a: show both local and remote tracking branches.
git-commit: show --summary after successful commit.
para-walk: walk n trees, index and working tree in parallel
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
rev-list --left-right
blame and pickaxe: --show-stats for easier optimization work.
^ permalink raw reply
* Re: What's in git.git
From: David Lang @ 2006-11-08 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8ximwrm3.fsf@assigned-by-dhcp.cox.net>
On Tue, 7 Nov 2006, Junio C Hamano wrote:
> [pu]
>
> Johannes's shallow clone work now should rebase cleanly on top
> of 'master' although I haven't done so yet. As he said
> himself the series is waiting for people who have needs for
> such a feature to raise hands.
I haven't been watching this recently, but if this is what I understand it to be
(the ability to get a partial repository from upstream and work normally from
there with the result of data-mineing tools sometimes reporting 'that's part of
the truncated history' if they hit the cutoff) consider my hand raised.
there are a number of cases where I would be interested in following a project
as it moves forwards, but do not have the need to have the full history (even
with the good compression that a git pack provides, it's still a significant
amount of disk space and download time for large projects)
^ permalink raw reply
* Re: [PATCH] Return non-zero status from pull if merge fails.
From: Shawn Pearce @ 2006-11-08 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7qmzttk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > diff --git a/git-merge.sh b/git-merge.sh
> > index cb09438..7725908 100755
> > --- a/git-merge.sh
> > +++ b/git-merge.sh
> > @@ -203,7 +203,7 @@ f,*)
> > git-update-index --refresh 2>/dev/null
> > new_head=$(git-rev-parse --verify "$1^0") &&
> > git-read-tree -u -v -m $head "$new_head" &&
> > - finish "$new_head" "Fast forward"
> > + finish "$new_head" "Fast forward" || exit 1
> > dropsave
> > exit 0
> > ;;
>
> The shell function "finish" itself exits when there is an error;
> is this needed?
Yes. Without it:
$ git checkout -b 931233bc666b^
$ echo broken >builtin-pickaxe.c
$ git pull . next && echo good merge
Updating c2e525d..522da27
builtin-pickaxe.c: needs update
fatal: Entry 'builtin-pickaxe.c' not uptodate. Cannot merge.
good merge
Say what? There's no way that fast forward was good! Granted this
use case is horrible but that fast forward went very, very badly,
but the caller now thinks it was good.
> > @@ -214,7 +214,7 @@ f,*)
> > + git var GIT_COMMITTER_IDENT >/dev/null || exit 1
> > @@ -225,7 +225,7 @@ f,*)
> > + ) || exit 1
> > @@ -253,7 +253,7 @@ f,*)
> > +git var GIT_COMMITTER_IDENT >/dev/null || exit 1
> > @@ -327,7 +327,7 @@ done
> > + result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit 1
>
> Are these needed? Wouldn't "something || exit" already exit non-zero
> when something exits non-zero?
Hmm; apparently you are correct. But that seems like magic shell
voodoo to me. I honestly didn't expect exit to behave like that.
Please delete these 4 hunks and apply my patch without them.
--
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Shawn Pearce @ 2006-11-08 5:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20061107231130.GA5141@steel.home>
Alex Riesen <fork0@t-online.de> wrote:
> I couldn't help noticing that the interface to the packs data is
> a bit complex:
>
> unsigned char *use_pack(struct packed_git *p,
> struct pack_window **window,
> unsigned long offset,
> unsigned int *left);
> void unuse_pack(struct pack_window **w);
>
> Or am I missing something very obvious, and something like this
> is just not feasible for some reasons?
The use counter. Every time someone asks for a pointer into the
pack they need to lock that window into memory to prevent us from
garbage collecting it by unmapping it to make room for another
window that the application needs.
> I was almost about to move your code into unpack_object_header_gently,
> but ... The header isn't that big, is it? It is variable in the pack,
> but the implementation of the parser is at the moment restricted by
> the type we use for object size (unsigned long for the particular
> platform). For example:
All true. However what happens when the header spans two windows?
Lets say I have the first 4 MiB mapped and the next 4 MiB mapped in
a different window; these are not necessarily at the same locations
within memory. Now if an object header is split over these two
then some bytes are at the end of the first window and the rest
are at the start of the next window.
I can't just say "make sure we have at least X bytes available
before starting to decode the header, as to do that in this case
we'd have to unmap BOTH windows and remap a new one which keeps
that very small header fully contiguous in memory. That's thrashing
the VM page tables for really no benefit.
> (BTW, current unpack_object_header_gently does not use it's len
> argument to check if there actually is enough data to hold at least
> minimal header. Is the size of mapped data checked for correctness
> somewhere before?)
Yes. Somewhere. I think we make sure there's at least 20 bytes
in the pack remaining before we start to decode a header. We must
have at least 20 as that's the trailing SHA1 checksum of the entire
pack. :-)
--
^ permalink raw reply
* Re: Did anyone have trouble learning the idea of local vs. remote branches?
From: Matthieu Moy @ 2006-11-08 5:19 UTC (permalink / raw)
To: git
In-Reply-To: <20061107172450.GA26591@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Today I was talking with someone that I collaborate with through
> Git and they still seemed to not get the idea that all branches
> in their repository are local, and that at least a 'git fetch'
> is needed to update the local tracking branches to the version
> in the central repository that we collaborate through. And this
> isn't the first time we've had such discussions.
To me, the biggest difficulty was to understand the vocubulary. I
started with cogito, and looked for branching features in cg-branch-*.
The /features/ themselves seem nice, but the names of commands are
confusing to me. I'd expect something called cg-branch-add to create a
new branch, while it just tells cogito where to find one. And the git
Vs cogito increased the confusion.
--
^ permalink raw reply
* Re: Did anyone have trouble learning the idea of local vs. remote branches?
From: Wink Saville @ 2006-11-08 5:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061107172450.GA26591@spearce.org>
As a newbie I'm confused, recently I attempted to get Andrew Morton's -mm "tree". It turns out the instructions were incorrect and Junio was kind enough to correct the mistake. But I for one am still confused.
git-fetch is; "Download objects and a head from another repository"
Fair enough and that make sense, but where does it go? Apparently it just gets stored in the object database and a reference to it in "FETCH_HEAD". Now what? Ok the documentation says:
'The information is left for a later merge operation done by "git merge"'
Now in the case of fetching -mm apparently you don't do a merge, instead the instructions now read:
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
The git-fetch apparently gets "linux-trees.git" and places a reference to it in a tag named 'v2.6.16-rc2-mm1'. Then the git-checkout, check's out this tag to a new branch, there was no merge! This is confusing and makes no sense to this newbie.
Now lets take a quick look at the git-merge documentation "HOW MERGE WORKS":
"A merge is always between the current HEAD and one or more remote branch heads, and the index file must exactly match the tree of HEAD commit (i.e. the contents of the last commit) when it happens. In other words, git-diff --cached HEAD must report no changes."
Sorry, there is basically no information in those two sentences that makes any sense to me. Take the first part, "between the current HEAD and one or more remote branch heads". So apparently merges occur against the current checkout branch, but I would guess the origin is also involved somehow? Secondly, what is the relationship between "remote branch heads" and FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used anywhere in the git-merge documentation. Then we come to "the index file must exactly match the tree HEAD commit", sorry but my question is how could it not match? Obviously I don't understand how the index file is used, but I can say that adding "git-diff --cached HEAD must report no no changes" adds nothing to the explanation, yet I'm sure it does mean something to an expert.
It then goes onto say "it may fetch the objects from remote" I thought that is what "fetch" does.
Anyway, as you can see there is room for confusion for some people.
Regards,
^ permalink raw reply
* Re: [PATCH] Return non-zero status from pull if merge fails.
From: Junio C Hamano @ 2006-11-08 5:36 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061108051035.GA28498@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Yes. Without it:
>
> $ git checkout -b 931233bc666b^
> $ echo broken >builtin-pickaxe.c
> $ git pull . next && echo good merge
> Updating c2e525d..522da27
> builtin-pickaxe.c: needs update
> fatal: Entry 'builtin-pickaxe.c' not uptodate. Cannot merge.
> good merge
>
> Say what? There's no way that fast forward was good! Granted this
> use case is horrible but that fast forward went very, very badly,
> but the caller now thinks it was good.
I think fast forward went Ok in that "git-ls-tree HEAD" gives
the correct merge result from pulling next on top of 931233^ (or
whatever). I am undecided if we want to keep what dropsave is
supposed to remove in that case, but exiting with non-zero to
indicate an error condition is needed.
> Hmm; apparently you are correct. But that seems like magic shell
> voodoo to me. I honestly didn't expect exit to behave like that.
Get used to it and learn the real shell programming from a
traditionalist ;-).
something-that-could-fail || exit
is a well established idiom.
But I do not mind the extra explicit non-zero exit status too
much as long as you are consistent.
^ permalink raw reply
* Re: [RFC] git-gui: A commit / fetch / push interface
From: Liu Yubao @ 2006-11-08 5:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn Pearce, git
In-Reply-To: <17745.3287.358673.265578@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Shawn Pearce writes:
>
>> I liked it and wanted to start making it available to some folks I
>> work with who are more comfortable with the mouse than they are with
>> the keyboard. At first I tried fixing a few of the outstanding bugs
>> in gitool but I eventually wound up rewriting the thing from scratch.
>
> Cool!
>
>> I have posted a repository with the source on pasky's service:
>>
>> http://repo.or.cz/w/git-gui.git
>
> Shouldn't the "w" be "r" there? It gave me an error "Can't lock ref"
> with the "w".
>
This it a gitweb URL, not a repos URL for 'git clone', you can only view
it in web browser.
^ permalink raw reply
* Re: [PATCH] Return non-zero status from pull if merge fails.
From: Shawn Pearce @ 2006-11-08 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01av6tb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Yes. Without it:
> >
> > $ git checkout -b 931233bc666b^
> > $ echo broken >builtin-pickaxe.c
> > $ git pull . next && echo good merge
> > Updating c2e525d..522da27
> > builtin-pickaxe.c: needs update
> > fatal: Entry 'builtin-pickaxe.c' not uptodate. Cannot merge.
> > good merge
> >
> > Say what? There's no way that fast forward was good! Granted this
> > use case is horrible but that fast forward went very, very badly,
> > but the caller now thinks it was good.
>
> I think fast forward went Ok in that "git-ls-tree HEAD" gives
> the correct merge result from pulling next on top of 931233^ (or
> whatever).
No it didn't. After doing the pull:
$ git rev-parse --verify HEAD
c2e525d97f81bc178567cdf4dd7056ce6224eb58
$ git rev-parse --verify 931233bc666b^
c2e525d97f81bc178567cdf4dd7056ce6224eb58
so no the merge result wasn't put into HEAD. Nothing was done.
Which is good because to do the merge the working directory has
to change but there's a conflict there due to one file being in a
modified state. Better we don't change HEAD.
> I am undecided if we want to keep what dropsave is
> supposed to remove in that case, but exiting with non-zero to
> indicate an error condition is needed.
I think that elsewhere in git-merge we abort without calling dropsave
when things to south. Which is why I aborted before.
--
^ permalink raw reply
* Re: [RFC] git-gui: A commit / fetch / push interface
From: Shawn Pearce @ 2006-11-08 5:55 UTC (permalink / raw)
To: Liu Yubao; +Cc: Paul Mackerras, git
In-Reply-To: <45516F21.9070901@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
> Paul Mackerras wrote:
> >Shawn Pearce writes:
> >
> >>I liked it and wanted to start making it available to some folks I
> >>work with who are more comfortable with the mouse than they are with
> >>the keyboard. At first I tried fixing a few of the outstanding bugs
> >>in gitool but I eventually wound up rewriting the thing from scratch.
> >
> >Cool!
> >
> >>I have posted a repository with the source on pasky's service:
> >>
> >> http://repo.or.cz/w/git-gui.git
> >
> >Shouldn't the "w" be "r" there? It gave me an error "Can't lock ref"
> >with the "w".
>
> This it a gitweb URL, not a repos URL for 'git clone', you can only view
> it in web browser.
Too bad pasky doesn't have the magic mapping setup in the webserver
so they are one and the same. :-)
I linked to the gitweb rather than the repository as I figured
people might want to read the history, or since it was just one
blob download it right from the webpage rather than cloning the
repository. But given that this is the git mailing list most people
probably would have expected to clone it instead...
--
^ permalink raw reply
* Re: [RFC] git-gui: A commit / fetch / push interface
From: Shawn Pearce @ 2006-11-08 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17745.3287.358673.265578@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
> One thing I have been meaning to do is to integrate gitool into gitk,
> now that gitk can display a fake commit showing the local changes. I
> intend to add a menu item to gitk saying "Commit local changes" or
> something, which would invoke gitool, or maybe now git-gui instead. :)
> The nice thing is that then gitk could update the graph to show the
> new commit once it was created.
Right. :-)
I have absolutely no plans (or desire) to attempt to do graph
rendering in git-gui. The most I may do for showing history in it
is perhaps a "git log --max-count=5 --pretty=oneline" type of display
so the user can see more than just an empty window after a commit.
IMHO gitk does a very nice job of rendering the graph on a wide
range of platforms (although it still has two annoying bugs: one
on Windows and one on Mac OS X that really make it hard to use).
git-gui is just an attempt to bring the other major features of Git
to that same set of platforms, with the same set of dependencies
(wish 8) and ease of use...
It would be nice if we can eventually connect gitk and git-gui so
they can coordinate as you are talking about above...
> My current version of gitool also has menus that let you revert
> modified files, and delete or ignore untracked files. Have you
> considered adding that to git-gui?
Yes, they are in my TODO list (or if missing from there are certainly
in my head as things to add). I'd like to get git-gui finished this
week, which means getting those features in today or tomorrow. :-)
I'll probably do branches first though.
--
^ permalink raw reply
* Re: Did anyone have trouble learning the idea of local vs. remote branches?
From: Shawn Pearce @ 2006-11-08 6:10 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <eiqi3f$ouq$1@sea.gmane.org>
Salikh Zakirov <Salikh.Zakirov@Intel.com> wrote:
> I think that the particular issue with the workflow in my organization
> could have been solved by the git-checkout and git-clone hybrid
>
> git-checkout ssh://path.to/repo.git#branch [work_dir]
>
> which would clone repository with just one branch and setup the remotes
> file accordingly (The syntax is completely made up, of course)
Right; that would help us to but developers really want two mainline
branches locally (stable and slightly less stable) as they access
them frequently.
Hence the "git clone --only a,b" syntax that was floating around
on the mailing list the past few days. Of course no implementation
exists yet...
> - there is a "mainline" branch of development, kept as ssh-shared git repository
> - mainline commits require some pre-commit testing, which takes ~1.5 hours,
> so people tend not to commit to mainline too often. On average, a given
> person commits to mainline once or twice a week.
> - mainlines commits also require a fellow developer review, that's where
> topic branches come in handy. Topic branches are also useful for testing,
> as pre-commit testing should be run on several different platforms, thus
> on a different machines. Topic branches are kept on the same shared server.
Pretty much the same workflow here; except that instead of a 1.5
hour testing requirement to move code into the mainline we have a
several day manual process where humans redo the changes that were
already made in git in the "real" SCM.
Usually humans screw up redoing those changes and it takes a few more
days to figure out why a topic branch it Git that works correctly
fails to even compile in the mainline. So we don't push to the
mainline often.
--
^ permalink raw reply
* [PATCH] clear error message for clone a gitweb URL
From: Liu Yubao @ 2006-11-08 7:25 UTC (permalink / raw)
To: git
When clone a gitweb URL, git reports "Can't lock ref", it's not clear for users,
this patch adds clear error message for this case.
diff --git a/fetch.c b/fetch.c
index c426c04..40c5183 100644
--- a/fetch.c
+++ b/fetch.c
@@ -266,6 +266,14 @@ int pull(int targets, char **target, con
if (!write_ref || !write_ref[i])
continue;
+ if (*write_ref[i] == '\0') {
+ if (strncmp(write_ref_log_details, "http", 4) == 0)
+ error("Can't feed empty ref, seems you are fetching from a gitweb URL, "
+ "check it in web browser for git URL.");
+ else
+ error("Can't feed empty ref");
+ goto unlock_and_fail;
+ }
lock[i] = lock_ref_sha1(write_ref[i], NULL);
if (!lock[i]) {
error("Can't lock ref %s", write_ref[i]);
diff --git a/git-clone.sh b/git-clone.sh
index 3f006d1..c8274e0 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -55,6 +55,10 @@ Perhaps git-update-server-info needs to
else
tname=$name
fi
+ if [ -z "$tname" -o -z "$name" ]; then
+ die "Cannot feed empty ref or commit-id, seems you are fetching
+from a gitweb URL, check it in web browser for git URL."
+ fi
git-http-fetch -v -a -w "$tname" "$name" "$1/" || exit 1
done <"$clone_tmp/refs"
^ permalink raw reply related
* Re: Did anyone have trouble learning the idea of local vs. remote branches?
From: Jakub Narebski @ 2006-11-08 7:29 UTC (permalink / raw)
To: git
In-Reply-To: <455169D1.8060408@saville.com>
Could you word-wrap your messages at some reasonable column, for example at
72 or 76-columns wide?
Wink Saville wrote:
> As a newbie I'm confused, recently I attempted to get Andrew Morton's
> -mm "tree".
Which is unusual git usage, as Andrew Morton uses Quilt/his own patch tools,
and not git, if I remember correctly.
> It turns out the instructions were incorrect and Junio was
> kind enough to correct the mistake. But I for one am still confused.
>
> git-fetch is; "Download objects and a head from another repository"
>
> Fair enough and that make sense, but where does it go? Apparently it just
> gets stored in the object database and a reference to it in "FETCH_HEAD".
> Now what? Ok the documentation says:
Objects gets stored into object database. Then (using FETCH_HEAD) heads
of tracking branches gets updated (i.e. if there were some changes on
branch 'master' in remote, the objects are downloaded, then head of local
tracking branch corresponding to remote branch 'master', e.g. 'origin',
gets updated with the value in 'master'; so called fast-forward case).
> 'The information is left for a later merge operation done by "git
> merge"'
Or done by git pull. The information in FETCH_HEAD is for commit message
in later merge (for example due to pull).
> Now in the case of fetching -mm apparently you don't do a merge, instead
> the instructions now read:
>
> $ git-fetch \
> git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git \
> tag v2.6.16-rc2-mm1
> $ git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
Are you sure that it is 'tag' there?
BTW. you are actually encouraged to use "git fetch" and "git checkout",
unless in scripts.
> The git-fetch apparently gets "linux-trees.git" and places a reference to
> it in a tag named 'v2.6.16-rc2-mm1'. Then the git-checkout, check's out
> this tag to a new branch, there was no merge! This is confusing and makes
> no sense to this newbie.
The git-fetch fetches _from_ linux-trees.git repository. It fetches tag
v2.6.16-rc2-mm1 (and its lineage, i.e. everything pointed by this tag,
transitively) and stores it as local tag v2.6.16-rc2-mm1. You cannot
checkout tag (you can't commit to tag), so you have to create new branch
for your changes (or for checkout).
> Now lets take a quick look at the git-merge documentation "HOW MERGE
> WORKS":
>
> "A merge is always between the current HEAD and one or more remote branch
> heads, and the index file must exactly match the tree of HEAD commit (i.e.
> the contents of the last commit) when it happens. In other words, git-diff
> --cached HEAD must report no changes."
That's a bit untrue, because merge can happen between local branches too.
> Sorry, there is basically no information in those two sentences that makes
> any sense to me. Take the first part, "between the current HEAD and one or
> more remote branch heads". So apparently merges occur against the current
> checkout branch, but I would guess the origin is also involved somehow?
Current HEAD is current checked out branch. You merge current HEAD and one
or more [remote] branch heads (in the pull case, those not marked
not-for-merge in FETCH_HEAD), and place result in current branch.
> Secondly, what is the relationship between "remote branch heads" and
> FETCH_HEAD? I see no mention of FETCH_HEAD or how it might be used
> anywhere in the git-merge documentation.
FETCH_HEAD is low-lewel, not to be used by end-user (unless he/she wants to
do something unusual).
> Then we come to "the index file
> must exactly match the tree HEAD commit", sorry but my question is how
> could it not match?
For example if you git-add'ed some files, but not committed the addition.
> Obviously I don't understand how the index file is
> used, but I can say that adding "git-diff --cached HEAD must report no no
> changes" adds nothing to the explanation, yet I'm sure it does mean
> something to an expert.
It adds command which you can use to check _why_ merge failed to run.
> It then goes onto say "it may fetch the objects from remote" I thought
> that is what "fetch" does.
IIRC this explanation is in git-pull(1). Pull in git is _fetch_ + merge.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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