* Re: merge into branch currently not active / checked out
From: Junio C Hamano @ 2007-06-17 9:27 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070617072225.GF23473@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> writes:
> Hello,
> is it possible to merge into a branch currently not active/checked out?
> I have the following scenario:
>
> - One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)
> - One upstream branch (master)
> - One branch that has every feature branch (tg)
>
> (faui00u) [~/work/mutt/mutt] git branch
> cstatus
> headers
> master
> mutt-collapse-flags
> small-fixes
> * tg
>
> I want to merge master in every of the feature branches. Is that possible or
> just bullshit because I don't have a working tree to handle conflicts?
Exactly. Merge would want to have working tree, so merging into
the current branch is not just the default but the only mode of
operation.
In general, I would recommend against merging 'master' to topic
branches, if you can avoid it.
There are two reasons you would ever want to merge 'master' to
them.
(1) You notice that 'master' has new stuff. It does not
necessarily conflict with the changes you made to your
topic branches, and it often doesn't, if the project is
well modularized. Still, you want to make sure that your
topic branches are compatible with it. IOW to see if the
changes in the master did not break your topic.
(2) You notice that 'master' actually have new change that
actively interact with what you set out to do in some of
your toipcs.
If you plan to eventually ask somebody who integrates the
'master' to pull from you, and keep the resulting development
history clean, (1) is _NOT_ a good reason to merge 'master' into
your topics. Because after your topic finally is finished, when
'master' pulls it, it will see many "senseless" merges from
itself.
Such "an integration testing" is better done, instead, by
forking a 'test' (perhaps throw-away) branch from 'master', and
merging all your topics into it.
On the other hand, (2) is a valid reason to resolve conflict
(both textual and semantic) early before you eventually present
your work for inclusion to 'master'.
Also, if you do not publish your work-in-progress topics, you
might want to consider rebasing on top of 'master', instead of
'merging'. Rebase can take the topic branch name and switch
your current branch for you when you give it, like so:
$ git rebase master topic1
$ git rebase master topic2
...
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Dirk Koopman @ 2007-06-17 9:10 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070617081959.GD1828@planck.djpig.de>
Frank Lichtenheld wrote:
> Hi.
>
> On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote:
>> Early cvs clients don't cause state->{args} to be initialised,
>> so force this to occur.
>> Some revision checking code assumes that revisions will be
>> recognisably numeric to perl, Branches are not, because they
>> have more decimal points (eg 1.2.3.4 instead of just 1.2).
<snip>
>
> Hmm, I don't see how you could have a problem with that since cvsserver
> doesn't support branches and never generates any revision numbers in
> that format?
>
> There is probably much more code out there in cvsserver that does assume
> that revision is always a simple integer.
>
> And again that comment is a but much IMHO.
>
The specific issue that I was trying to solve is that I have (in CVS
terms) a main line (git head: master) and an active CVS development
branch and git head (called SR [for the sake of argument]).
I have imported both into git using cvsimport. For compatibility (and
windows users) I need a anonymous, read only, :pserver: CVS
implementation that can serve either head.
The version numbers in the CVS import on branch SR are standard CVS
single level branch 1.2.3.4. Doing a 'cvs update' on this branch was
causing all sorts of warnings about 1.2.3.4 not being numeric on that
test. After changing the test, the warnings have gone away and it all
still seems to work.
Having said that, I haven't worked out where cvsserver is getting those
version numbers from in the first place, but it obviously knows that it
is dealing with a branch sufficient to work well enough for my needs.
Of course, quite what happens when the branch merges back and people
want to 'cvs update -A', I shall leave for the future...
Groetjes Dirk
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Catalin Marinas @ 2007-06-17 8:54 UTC (permalink / raw)
To: Josef Sipek; +Cc: Yann Dirson, Karl Hasselström, Steven Grimm, git
In-Reply-To: <20070617035923.GI7025@filer.fsl.cs.sunysb.edu>
On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:
> Then there is the psychological effect. If I have a directory full of
> patch(1) compatible diff files, I can forget about guilt and just use the
> diff files directly. With stgit's way of storing the patches, I'd assume
> things can get a bit harder if you just want to give up on stgit.
I do this a lot to refine patches but I export the patch and re-import
it (I can even merge it with the old version using 'stg fold
--threeway' and it will prompt me for the differences via xxdiff or
emacs).
> Btw, does git-prune & friends do the right thing and not destroy the
> patch-related objects?
StGIT patches are git-prune safe. The commit ids are stored in
.git/refs/patches.
> > Well, people may not like python, but IMHO it is a lot easier to learn
> > it if you don't know it (that's what I did, although I did not start
> > from zero), than writing a robust and maintainable software of even
> > moderate complexity in shell script. Shell script may be good for
> > prototyping or gluing tools in a simple way, but for advanced sofware
> > on which to rely to store my own data, it is just not really suited.
>
> So, why do you use git? ;)
Well, I guess he's mostly using StGIT which uses only the built-in GIT
commands written in C :-).
--
Catalin
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Catalin Marinas @ 2007-06-17 8:46 UTC (permalink / raw)
To: Josef Sipek; +Cc: Karl Hasselström, Steven Grimm, git
In-Reply-To: <20070617035426.GH7025@filer.fsl.cs.sunysb.edu>
On 17/06/07, Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:
> On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
> > I haven't tried quilt either but, if it uses plain text patches, the
> > disadvantage might be the losing of the three-way merge when pushing a
> > patch onto the stack. The solution is to remember which commit the
> > patch applies to, switch the tree, apply the patch and merge with
> > HEAD.
>
> Catalin: Perhaps a comparison table might be in order? This is most
> definitely not the first time this question has been asked.
Yes, a table on a wiki (maybe a neutral one like git.or.cz?) would be
good as it is easier to keep up to date.
> > Are the guilt patches accessible as commit objects at the top of the
> > stack?
>
> When you push a patch, you're doing:
>
> git-apply && git-commit
StGIT's behaviour is more like:
(git-apply || git-recursive-merge) && git-commit
i.e. if simple git-apply fails, it tries a proper three-way merge and
can automatically invoke a graphical merge tool (xxdiff, emacs etc.).
The input to git-apply is generated by git-diff with the top and
bottom commit ids of the patch as arguments. People mentioned that
would be good to keep the plain diff and just apply it but we might
still need to generate the patch after a push and hence call git-diff.
It might work if we only regenerate the patch when git-apply fails and
we run a recursive merge. Actually StGIT notifies you when the 'push'
resulted in a modified patch so that one can re-export it.
Aome other features of 'push' is automatic detection of patches merged
upstream (either by trying a reverse-apply or an empty patch resulting
from a three-way merge). It can also do fast-forwarding if the base
tree hasn't changed.
> When you pop a patch, you're doing:
>
> git-reset --hard HEAD^
StGIT uses git-read-tree as it is safer with unresolved conflicts and
local changes.
> > StGIT might have some more features as it is older but I see a lot of
> > development is going on with guilt.
>
> I haven't looked at stgit in a number of months, but stgit most likely has
> many features which make use of the extra metadata stored.
Most of the metada could actually be generated from the commit object.
We just store it for performance. However, with some recent DAG
patches from Karl, we plan to get this information directly from the
repository.
> I'm trying to take the simpler approach - most of the time, the user just
> want to push, refresh, and pop. With that said, there are plenty of useful
> commands (26 as of now).
StGIT started with these too but it grew to 41.
> One additional thing. About four months ago, I've heard that stgit tends to
> blow up when you switch branches using git-checkout - guilt of course
> doesn't :) My information may be outdated, so corrections are welcome.
Not sure what you mean but it is safe to use git-checkout to switch
branches and use them with StGIT afterwards, assuming they were
initialised for StGIT (though StGIT has its own command for managing
branches).
Some other useful commands in StGIT are 'mail' (to SMTP or mbox),
'export' (to quilt series), 'import' (from various sources like quilt
series, e-mail message, mbox). It also support templates for the mail
and export commands and various configuration options (shares the
.git/config file and adds a [stgit] section).
--
Catalin
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Frank Lichtenheld @ 2007-06-17 8:19 UTC (permalink / raw)
To: Dirk Koopman; +Cc: git
In-Reply-To: <11820198064114-git-send-email-djk@tobit.co.uk>
Hi.
On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote:
> Early cvs clients don't cause state->{args} to be initialised,
> so force this to occur.
> Some revision checking code assumes that revisions will be
> recognisably numeric to perl, Branches are not, because they
> have more decimal points (eg 1.2.3.4 instead of just 1.2).
> ---
> git-cvsserver.perl | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 5cbf27e..0a4b75e 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -1813,11 +1813,14 @@ sub req_annotate
> # the second is $state->{files} which is everything after it.
> sub argsplit
> {
> + $state->{args} = []; # need this here because later code depends on it
> + # and for some reason earlier versions of CVS don't
> + # satisfy the next condition on plain 'cvs update'
> +
> return unless( defined($state->{arguments}) and ref $state->{arguments} eq "ARRAY" );
>
> my $type = shift;
>
> - $state->{args} = [];
> $state->{files} = [];
> $state->{opt} = {};
>
I just would move all the initializations up there. And I think the
comment is really unnecessary. Will prepare a replacement patch.
> @@ -1906,11 +1909,13 @@ sub argsfromdir
>
> # push added files
> foreach my $file (keys %{$state->{entries}}) {
> - if ( exists $state->{entries}{$file}{revision} &&
> - $state->{entries}{$file}{revision} == 0 )
> - {
> - push @gethead, { name => $file, filehash => 'added' };
> - }
> + # remember that revisions could be on branches 1.2.3.4[.5.6..]
> + # not just a recogisable "numeric" 1.2
> + if ( exists $state->{entries}{$file}{revision} &&
> + !$state->{entries}{$file}{revision} )
> + {
> + push @gethead, { name => $file, filehash => 'added' };
> + }
> }
>
> if ( scalar(@{$state->{args}}) == 1 )
Hmm, I don't see how you could have a problem with that since cvsserver
doesn't support branches and never generates any revision numbers in
that format?
There is probably much more code out there in cvsserver that does assume
that revision is always a simple integer.
And again that comment is a but much IMHO.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Simon Hausmann @ 2007-06-17 8:11 UTC (permalink / raw)
To: git
In-Reply-To: <466DF32D.802@xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Tuesday 12 June 2007 03:13:17 Han-Wen Nienhuys wrote:
> Benjamin Sergeant escreveu:
> > A perforce command with all the files in the repo is generated to get
> > all the file content.
> > Here is a patch to break it into multiple successive perforce command
> > who uses 4K of parameter max, and collect the output for later.
> >
> > It works, but not for big depos, because the whole perforce depo
> > content is stored in memory in P4Sync.run(), and it looks like mine is
> > bigger than 2 Gigs, so I had to kill the process.
>
> General idea of the patch is ok. some nits:
> > + chunk = ''
> > + filedata = []
> > + for i in xrange(len(files)):
>
> why not
>
> for f in files:
>
> ?
It seems 'i' is used a bit later. Is there a nicer way to express this in
python?
> > + f = files[i]
> > + chunk += '"%s#%s" ' % (f['path'], f['rev'])
> > + if len(chunk) > 4000 or i == len(files)-1:
>
> 4k seems reasonable enough, but can you take the min() with
> os.sysconf('SC_ARG_MAX') ?
>
> Can you address this and resend so we can apply the patch?
> Thanks.
Since I ran into the very problem of a too long commandline myself yesterday I
took the liberty of adding the SC_ARG_MAX bit to Benjamin's patch and
comitting it then.
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: t5515 in general
From: Junio C Hamano @ 2007-06-17 8:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706170034540.4740@iabervon.org>
In general I would agree that the whole "backward compatible"
thing we do with .git/branches and then .git/remotes when we
really went to the new model of using .git/config primarily was
done too cautiously, in that the configuration would not affect
existing setup that used branches and remotes, as they did not
have any way to express those new concepts (i.e. per branch
default remote, and per branch default merge sources).
I am actually in favor of killing .git/branches support way
before we do 1.6.0, and .git/remotes by the time we do 1.6.0.
But if you can arrange the url/fetch configurations to be still
taken from these old locations while applying per-branch default
remote and merge from .git/config, that would probably be easier
for people to migrate to .git/config only style.
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Thomas Glanzmann @ 2007-06-17 8:01 UTC (permalink / raw)
To: GIT
In-Reply-To: <20070608110536.GD2335@cip.informatik.uni-erlangen.de>
Hello,
the machine came back with a new power supply. And guess what:
(tomcat-05) [/usr/src] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /usr/src/linux-2.6/.git/
remote: Generating pack...
remote: Done counting 499634 objects.
remote: Deltifying 499634 objects...
remote: 100% (499634/499634) done
Indexing 499634 objects...
remote: Total 499634 (delta 403845), reused 495761 (delta 400337)
100% (499634/499634) done
Resolving 403845 deltas...
100% (403845/403845) done
Checking 22411 files out...
100% (22411/22411) done
Thomas
^ permalink raw reply
* merge into branch currently not active / checked out
From: Thomas Glanzmann @ 2007-06-17 7:22 UTC (permalink / raw)
To: GIT
Hello,
is it possible to merge into a branch currently not active/checked out?
I have the following scenario:
- One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)
- One upstream branch (master)
- One branch that has every feature branch (tg)
(faui00u) [~/work/mutt/mutt] git branch
cstatus
headers
master
mutt-collapse-flags
small-fixes
* tg
I want to merge master in every of the feature branches. Is that possible or
just bullshit because I don't have a working tree to handle conflicts?
Thomas
^ permalink raw reply
* Problem with archimport
From: David Kastrup @ 2007-06-17 7:09 UTC (permalink / raw)
To: git
Hi, I am trying to import a large arch directory, and after a long
time of importing, I finally hit the following (unfortunately
repeatable) problem:
git-archimport -f emacs@sv.gnu.org/emacs--{devo,multi-tty,unicode}
Will import patchsets using the fast strategy
Renamed directories and permission changes will be missed
Unclean tree when about to process emacs@sv.gnu.org/emacs--devo--0--base-0 - did we fail to commit cleanly before?
:100644 100644 9bd88350a9553784a48ea1d5fa71484a7b200117 0000000000000000000000000000000000000000 M lisp/.arch-inventory
Any idea what to do about this?
Thanks,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* t5515 in general
From: Daniel Barkalow @ 2007-06-17 6:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
It looks to me like t5515 enshrines a number of infelicities in the
current fetch code. For example, if you have a branch configuration which
specifies a remote that's configured through a branches/* file, and you
have a merge setting for the branch, it's ignored, and we test that it's
ignored with a whole bunch of tests. I think that the behavior here should
either be unspecified, or we should make it more generally consistant
(i.e., if you specify any "merge" items, this overrides the default of
using the first refspec, even if the first refspec is implicit in the fact
that you're using a branches/* file, which automatically only has the
configured refspec refs/heads/master:). Or leave it unspecified and
untested, since neither option is actually useful.
This makes me think that a lot of t5515 was done by putting together a
bunch of configurations and automatically making tests for them without
checking whether the current behaviour is actually something we want, or
whether the configuration even could do anything sensible in the first
place. So it might be worth going through that set and eliminating
anything not actually predicted by the documentation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Josef Sipek @ 2007-06-17 3:59 UTC (permalink / raw)
To: Yann Dirson
Cc: Catalin Marinas, Karl Hasselström, Steven Grimm,
'git'
In-Reply-To: <20070615200139.GS6992@nan92-1-81-57-214-146.fbx.proxad.net>
On Fri, Jun 15, 2007 at 10:01:39PM +0200, Yann Dirson wrote:
> On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
...
> However, storing diffs is certainly a great way to interact with
> legacy SCMs, and there are situations where guilt is certainly more
> suited than stgit. Eg, on a project where you have to use CVS, and
> you have to maintain changes to a Linux kernel, and you want to store
> the history of a series of patches, guilt will be much easier to use
> than stgit.
Then there is the psychological effect. If I have a directory full of
patch(1) compatible diff files, I can forget about guilt and just use the
diff files directly. With stgit's way of storing the patches, I'd assume
things can get a bit harder if you just want to give up on stgit.
Btw, does git-prune & friends do the right thing and not destroy the
patch-related objects?
...
> Well, people may not like python, but IMHO it is a lot easier to learn
> it if you don't know it (that's what I did, although I did not start
> from zero), than writing a robust and maintainable software of even
> moderate complexity in shell script. Shell script may be good for
> prototyping or gluing tools in a simple way, but for advanced sofware
> on which to rely to store my own data, it is just not really suited.
So, why do you use git? ;)
Josef "Jeff" Sipek.
--
The box said "Windows XP or better required". So I installed Linux.
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Josef Sipek @ 2007-06-17 3:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Steven Grimm, 'git'
In-Reply-To: <tnx1wgds1pv.fsf@arm.com>
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
> Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
> >
> >> I've asked this on IRC a couple times and nobody seemed to have a
> >> good answer, so: These two tools seem like they are solving the same
> >> general problem using similar approaches. They are both under active
> >> development. In what areas is each of them stronger than the other?
> >> Why would one choose to use one of them instead of the other?
> >
> > I have never had a close look at guilt, but from what I remember it
> > stores patches as plain old plaintext patches (corrections to this
> > statement welcome). StGIT uses git's object database.
Sorry I missed this thread...
> I haven't tried quilt either but, if it uses plain text patches, the
> disadvantage might be the losing of the three-way merge when pushing a
> patch onto the stack. The solution is to remember which commit the
> patch applies to, switch the tree, apply the patch and merge with
> HEAD.
Catalin: Perhaps a comparison table might be in order? This is most
definitely not the first time this question has been asked.
> Are the guilt patches accessible as commit objects at the top of the
> stack?
When you push a patch, you're doing:
git-apply && git-commit
When you pop a patch, you're doing:
git-reset --hard HEAD^
So, once a patch is pushes, it is a separate commit in the git tree, and one
can run any valid git command on it.
Now, of course the actual implementation is little bit more complex (e.g.,
using git-write-tree and git-commit-tree, as well as allowing to pop several
patches at the same time).
> StGIT might have some more features as it is older but I see a lot of
> development is going on with guilt.
I haven't looked at stgit in a number of months, but stgit most likely has
many features which make use of the extra metadata stored.
I'm trying to take the simpler approach - most of the time, the user just
want to push, refresh, and pop. With that said, there are plenty of useful
commands (26 as of now).
> I would welcome such a discussion (so please keep me cc'ed) as we can
> share the experience with various issues.
Same here.
One additional thing. About four months ago, I've heard that stgit tends to
blow up when you switch branches using git-checkout - guilt of course
doesn't :) My information may be outdated, so corrections are welcome.
Josef "Jeff" Sipek.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
^ permalink raw reply
* Re: [PATCH] Cloning from a repo without "current branch"
From: Junio C Hamano @ 2007-06-17 3:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <200706162226.l5GMQBss004492@mi0.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> diff --git a/git-clone.sh b/git-clone.sh
> index 3a41062..bd44ce1 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -377,6 +377,13 @@ then
> )
> )
>
> + # Upstream URL
> + git-config remote."$origin".url "$repo" &&
> +
> + # Set up the mappings to track the remote branches.
> + git-config remote."$origin".fetch \
> + "+refs/heads/*:$remote_top/*" '^$' &&
> +
> # Write out remote.$origin config, and update our
> "$head_points_at".
> case "$head_points_at" in
> ?*)
Whitespace breakage?
> @@ -384,21 +391,20 @@ then
> git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
>
> # Tracking branch for the primary branch at the remote.
> - origin_track="$remote_top/$head_points_at" &&
> git-update-ref HEAD "$head_sha1" &&
>
> - # Upstream URL
> - git-config remote."$origin".url "$repo" &&
> -
> - # Set up the mappings to track the remote branches.
> - git-config remote."$origin".fetch \
> - "+refs/heads/*:$remote_top/*" '^$' &&
> rm -f "refs/remotes/$origin/HEAD"
> git-symbolic-ref "refs/remotes/$origin/HEAD" \
> "refs/remotes/$origin/$head_points_at" &&
>
> git-config branch."$head_points_at".remote "$origin" &&
> git-config branch."$head_points_at".merge
> "refs/heads/$head_points_at"
> + ;;
Again...?
> + '')
> + # Source had detached HEAD pointing nowhere
> + git-update-ref --no-deref HEAD "$head_sha1" &&
> + rm -f "refs/remotes/$origin/HEAD"
> + ;;
> esac
>
> case "$no_checkout" in
> --
> 1.5.2
^ permalink raw reply
* Re: config-glob-octopus
From: Daniel Barkalow @ 2007-06-17 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzt71hks.fsf@assigned-by-dhcp.pobox.com>
On Sat, 16 Jun 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > With this configuration:
> >
> > [remote "config-glob"]
> > fetch = refs/heads/one:refs/remotes/rem/one
> > fetch = refs/heads/two:refs/remotes/rem/two
> > fetch = refs/heads/three:refs/remotes/rem/three
> > [branch "br-config-glob-octopus"]
> > remote = config-glob
> > merge = refs/heads/one
> > merge = two
> > merge = remotes/rem/three
> >
> > It seems to me like "two" should be marked for merge, since "two"
> > canonicalizes to "refs/heads/two", which matches the pattern and is
> > fetched. However, current git-fetch marks it not-for-merge, and the test
> > demands this.
> >
> > Shouldn't the value of "merge" permit the same shortcuts that the lhs of
> > "fetch" permits, even if the matching fetch line isn't using them in this
> > case? (And vice versa, for a canonical value of merge when the fetch is a
> > shortcut)
>
> I do not see much reason for that kind of complication.
> Honestly speaking, I do not like the fallback that we use for
> the third one (using the remote tracking name).
Actually, with my current code it's a simplification to have the code
expand all shortcuts up front and do all of the matching on explicit
names. I'm trying to use "struct ref" for fetching, and it doesn't work if
you have to store both the name that would match a "merge" setting and the
name that would match the actual remote ref.
> When you are righting down your configuration file, you are
> doing so to reuse that entry over and over, so why not be
> explicit for once and not worry about cases where the remote
> adds ambiguous 'two' that is not refs/heads/two?
I'd personally be in favor of requiring the config file to be explicit
everywhere, for just this reason, but we've got tests, if not
documentation (and I haven't checked documentation on this one) saying
that shortcuts work in config files.
This is, this is supported, and marks refs/heads/two for merge:
[remote "config-glob"]
fetch = refs/heads/one:refs/remotes/rem/one
fetch = two:refs/remotes/rem/two
fetch = refs/heads/three:refs/remotes/rem/three
[branch "br-config-glob-octopus"]
remote = config-glob
merge = refs/heads/one
merge = two
merge = remotes/rem/three
But I'd prefer to by able to discard the information of whether a short
form was used early.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.2.2
From: Junio C Hamano @ 2007-06-17 1:57 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
GIT v1.5.2.2 Release Notes
==========================
Fixes since v1.5.2.1
--------------------
* Usability fix
- git-gui is shipped with its updated blame interface. It is
rumored that the older one was not just unusable but was
active health hazard, but this one is actually pretty.
Please see for yourself.
* Bugfixes
- "git checkout fubar" was utterly confused when there is a
branch fubar and a tag fubar at the same time. It correctly
checks out the branch fubar now.
- "git clone /path/foo" to clone a local /path/foo.git
repository left an incorrect configuration.
- "git send-email" correctly unquotes RFC 2047 quoted names in
the patch-email before using their values.
- We did not accept number of seconds since epoch older than
year 2000 as a valid timestamp. We now interpret positive
integers more than 8 digits as such, which allows us to
express timestamps more recent than March 1973.
- git-cvsimport did not work when you have GIT_DIR to point
your repository at a nonstandard location.
- Some systems (notably, Solaris) lack hstrerror() to make
h_errno human readable; prepare a replacement
implementation.
- .gitignore file listed git-core.spec but what we generate is
git.spec, and nobody noticed for a long time.
- "git-merge-recursive" does not try to run file level merge
on binary files.
- "git-branch --track" did not create tracking configuration
correctly when the branch name had slash in it.
- The email address of the user specified with user.email
configuration was overriden by EMAIL environment variable.
- The tree parser did not warn about tree entries with
nonsense file modes, and assumed they must be blobs.
- "git log -z" without any other request to generate diff still
invoked the diff machinery, wasting cycles.
* Documentation
- Many updates to fix stale or missing documentation.
- Although our documentation was primarily meant to be formatted
with AsciiDoc7, formatting with AsciiDoc8 is supported better.
----------------------------------------------------------------
Changes since v1.5.2.1 are as follows:
Alex Riesen (3):
Make the installation target of git-gui a little less chatty
Fix clone to setup the origin if its name ends with .git
Add a local implementation of hstrerror for the system which do not have it
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Jakub Narebski (1):
Generated spec file to be ignored is named git.spec and not git-core.spec
Johannes Schindelin (2):
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
Johannes Sixt (1):
Accept dates before 2000/01/01 when specified as seconds since the epoch
Junio C Hamano (6):
checkout: do not get confused with ambiguous tag/branch names
$EMAIL is a last resort fallback, as it's system-wide.
git-branch --track: fix tracking branch computation.
Avoid diff cost on "git log -z"
Documentation: adjust to AsciiDoc 8
GIT 1.5.2.2
Kristian H淡gsberg (1):
Unquote From line from patch before comparing with given from address.
Luiz Fernando N. Capitulino (1):
git-cherry: Document 'limit' command-line option
Matthijs Melchior (1):
New selection indication and softer colors
Michael Milligan (1):
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
Sam Vilain (2):
fix documentation of unpack-objects -n
Don't assume tree entries that are not dirs are blobs
Shawn O. Pearce (47):
git-gui: Allow creating a branch when none exists
git-gui: Allow as few as 0 lines of diff context
git-gui: Don't quit when we destroy a child widget
git-gui: Attach font_ui to all spinbox widgets
git-gui: Verify Tcl/Tk is new enough for our needs
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Add a 4 digit commit abbreviation to the blame viewer
git-gui: Cleanup blame::new widget initialization
git-gui: Remove empty blank line at end of blame
git-gui: Improve the coloring in blame viewer
git-gui: Simplify consecutive lines that come from the same commit
git-gui: Use arror cursor in blame viewer file data
git-gui: Display tooltips in blame viewer
git-gui: Highlight the blame commit header from everything else
git-gui: Remove unnecessary reshow of blamed commit
git-gui: Cleanup minor style nit
git-gui: Space the commit group continuation out in blame view
git-gui: Show author initials in blame groups
git-gui: Allow the user to control the blame/commit split point
git-gui: Display a progress bar during blame annotation gathering
git-gui: Allow digging through history in blame viewer
git-gui: Combine blame groups only if commit and filename match
git-gui: Show original filename in blame tooltip
git-gui: Use a label instead of a button for the back button
git-gui: Clip the commit summaries in the blame history menu
git-gui: Remove the loaded column from the blame viewer
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Use lighter colors in blame view
git-gui: Make the line number column slightly wider in blame
git-gui: Automatically expand the line number column as needed
git-gui: Remove unused commit_list from blame viewer
git-gui: Better document our blame variables
git-gui: Cleanup redundant column management in blame viewer
git-gui: Switch internal blame structure to Tcl lists
git-gui: Label the uncommitted blame history entry
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Display the "Loading annotation..." message in italic
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display both commits in our tooltips
git-gui: Jump to original line in blame viewer
git-gui: Use three colors for the blame viewer background
git-gui: Improve our labeling of blame annotation types
git-gui: Favor the original annotations over the recent ones
git-gui: Changed blame header bar background to match main window
git-gui: Include 'war on whitespace' fixes from git.git
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Save geometry before the window layout is damaged
william pursell (1):
Make command description imperative statement, not third-person present.
^ permalink raw reply
* Re: config-glob-octopus
From: Junio C Hamano @ 2007-06-17 1:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706162039530.4740@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> With this configuration:
>
> [remote "config-glob"]
> fetch = refs/heads/one:refs/remotes/rem/one
> fetch = refs/heads/two:refs/remotes/rem/two
> fetch = refs/heads/three:refs/remotes/rem/three
> [branch "br-config-glob-octopus"]
> remote = config-glob
> merge = refs/heads/one
> merge = two
> merge = remotes/rem/three
>
> It seems to me like "two" should be marked for merge, since "two"
> canonicalizes to "refs/heads/two", which matches the pattern and is
> fetched. However, current git-fetch marks it not-for-merge, and the test
> demands this.
>
> Shouldn't the value of "merge" permit the same shortcuts that the lhs of
> "fetch" permits, even if the matching fetch line isn't using them in this
> case? (And vice versa, for a canonical value of merge when the fetch is a
> shortcut)
I do not see much reason for that kind of complication.
Honestly speaking, I do not like the fallback that we use for
the third one (using the remote tracking name).
When you are righting down your configuration file, you are
doing so to reuse that entry over and over, so why not be
explicit for once and not worry about cases where the remote
adds ambiguous 'two' that is not refs/heads/two?
^ permalink raw reply
* config-glob-octopus
From: Daniel Barkalow @ 2007-06-17 1:02 UTC (permalink / raw)
To: git
With this configuration:
[remote "config-glob"]
fetch = refs/heads/one:refs/remotes/rem/one
fetch = refs/heads/two:refs/remotes/rem/two
fetch = refs/heads/three:refs/remotes/rem/three
[branch "br-config-glob-octopus"]
remote = config-glob
merge = refs/heads/one
merge = two
merge = remotes/rem/three
It seems to me like "two" should be marked for merge, since "two"
canonicalizes to "refs/heads/two", which matches the pattern and is
fetched. However, current git-fetch marks it not-for-merge, and the test
demands this.
Shouldn't the value of "merge" permit the same shortcuts that the lhs of
"fetch" permits, even if the matching fetch line isn't using them in this
case? (And vice versa, for a canonical value of merge when the fetch is a
shortcut)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] cvsserver: Actually implement --export-all
From: Junio C Hamano @ 2007-06-17 1:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Frank Lichtenheld, Git Mailing List, Martin Langhoff
In-Reply-To: <20070616235250.GA3231@steel.home>
Thanks.
^ permalink raw reply
* Re: [PATCH] cvsserver: Actually implement --export-all
From: Alex Riesen @ 2007-06-16 23:52 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, Git Mailing List, Martin Langhoff
In-Reply-To: <11818693133098-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld, Fri, Jun 15, 2007 03:01:53 +0200:
> +test_expect_failure 'req_Root failure (export-all w/o whitelist)' \
> + 'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1
> + || false'
This does not work, at least for bash in current Ubuntu:
GNU bash, version 3.2.13(1)-release
You have to put "||" on the previous line:
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index b442b5d..0331770 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -180,8 +180,8 @@ test_expect_success 'req_Root (export-all)' \
tail -n1 log | grep -q "^I LOVE YOU$"'
test_expect_failure 'req_Root failure (export-all w/o whitelist)' \
- 'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1
- || false'
+ 'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1 ||
+ false'
test_expect_success 'req_Root (everything together)' \
'cat request-base | git-cvsserver --export-all --strict-paths --base-path $WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
^ permalink raw reply related
* Re: [PATCH 11/11] Document git commit --untracked-files and --verbose
From: Jakub Narebski @ 2007-06-16 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6ob3br0.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> +-u|--untracked-files::
>> + Show all untracked files, also those in uninteresting
>> + directories.
>> +
>> +-v|--verbose::
>> + Show the diff output between the HEAD commit and what
>> + would be committed.
>> +
>
> Thanks -- "show" sounds a bit funny, though, don't you think?
First, the description above has to be suitable both for git-commit and
for git-status, as both commands share options. Nevertheless those
options have slight different meaning: git-status print what is
"shown", in git-commit what is "shown" appears in the editor as/in
prepared commit message (printed using git-[run]status).
Second, this is last patch in the series... ;-)
Feel free to correct it if you have better idea for description of those
options.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Cloning from a repo without "current branch"
From: Nanako Shiraishi @ 2007-06-16 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If the remote repository does not have a "current branch", git-clone
was
confused and did not set up the resulting new repository correctly.
It did
not reset HEAD from the default 'master', and did not write the SHA1
to the master branch.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
diff --git a/git-clone.sh b/git-clone.sh
index 3a41062..bd44ce1 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -377,6 +377,13 @@ then
)
)
+ # Upstream URL
+ git-config remote."$origin".url "$repo" &&
+
+ # Set up the mappings to track the remote branches.
+ git-config remote."$origin".fetch \
+ "+refs/heads/*:$remote_top/*" '^$' &&
+
# Write out remote.$origin config, and update our
"$head_points_at".
case "$head_points_at" in
?*)
@@ -384,21 +391,20 @@ then
git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
# Tracking branch for the primary branch at the remote.
- origin_track="$remote_top/$head_points_at" &&
git-update-ref HEAD "$head_sha1" &&
- # Upstream URL
- git-config remote."$origin".url "$repo" &&
-
- # Set up the mappings to track the remote branches.
- git-config remote."$origin".fetch \
- "+refs/heads/*:$remote_top/*" '^$' &&
rm -f "refs/remotes/$origin/HEAD"
git-symbolic-ref "refs/remotes/$origin/HEAD" \
"refs/remotes/$origin/$head_points_at" &&
git-config branch."$head_points_at".remote "$origin" &&
git-config branch."$head_points_at".merge
"refs/heads/$head_points_at"
+ ;;
+ '')
+ # Source had detached HEAD pointing nowhere
+ git-update-ref --no-deref HEAD "$head_sha1" &&
+ rm -f "refs/remotes/$origin/HEAD"
+ ;;
esac
case "$no_checkout" in
--
1.5.2
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com
^ permalink raw reply related
* [PATCH] Fix ALLOC_GROW calls with obsolete semantics
From: Jeff King @ 2007-06-16 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
ALLOC_GROW now expects the 'nr' argument to be "how much you
want" and not "how much you have". This fixes all cases
where we weren't previously adding anything to the 'nr'.
Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of the add-empty topic in next. Your other uses of
ALLOC_GROW are presumably OK since they were already adding in extra
space.
dir.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index 98e24ad..8d8faf5 100644
--- a/dir.c
+++ b/dir.c
@@ -286,7 +286,7 @@ struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int
if (cache_name_pos(pathname, len) >= 0)
return NULL;
- ALLOC_GROW(dir->entries, dir->nr, dir->alloc);
+ ALLOC_GROW(dir->entries, dir->nr+1, dir->alloc);
return dir->entries[dir->nr++] = dir_entry_new(pathname, len);
}
@@ -295,7 +295,7 @@ struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char *pathname,
if (cache_name_pos(pathname, len) >= 0)
return NULL;
- ALLOC_GROW(dir->ignored, dir->ignored_nr, dir->ignored_alloc);
+ ALLOC_GROW(dir->ignored, dir->ignored_nr+1, dir->ignored_alloc);
return dir->ignored[dir->ignored_nr++] = dir_entry_new(pathname, len);
}
--
1.5.2.2.1012.ge05f4
^ permalink raw reply related
* Re: Fix up ugly open-coded "alloc_nr()" user in object.c
From: Jeff King @ 2007-06-16 22:37 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20070616221506.GA78651@dspnet.fr.eu.org>
On Sun, Jun 17, 2007 at 12:15:06AM +0200, Olivier Galibert wrote:
> > + ALLOC_GROW(array->objects, array->nr, array->alloc);
>
> Unless the ALLOC_GROW semantics are weird, shouldn't that be:
> ALLOC_GROW(array->objects, array->nr+1, array->alloc);
The semantics are weird. They never seemed so to me before, since it was
replacing some "grow by 1" areas where it is natural to assume that you
need just one spot more. But the way Junio commented it and tweaked it,
it can handle arbitrary growth (which is much better), but that means we
are overly conservative about when to grow.
Junio, patch is below (call-sites using bare 'nr' need to be 'nr+1', but
I will fix those up in a separate patch since they are in next and this
is in master).
-- >8 --
fix ALLOC_GROW off-by-one
The ALLOC_GROW macro will never let us fill the array completely,
instead allocating an extra chunk if that would be the case. This is
because the 'nr' argument was originally treated as "how much we do have
now" instead of "how much do we want". The latter makes much more
sense because you can grow by more than one item.
This off-by-one never resulted in an error because it meant we were
overly conservative about when to allocate. Any callers which passed
"how we have now" need to be updated, or they will fail to allocate
enough.
Signed-off-by: Jeff King <peff@peff.net>
---
cache.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index c914c1c..ed83d92 100644
--- a/cache.h
+++ b/cache.h
@@ -234,7 +234,7 @@ extern void verify_non_filename(const char *prefix, const char *name);
*/
#define ALLOC_GROW(x, nr, alloc) \
do { \
- if ((nr) >= alloc) { \
+ if ((nr) > alloc) { \
if (alloc_nr(alloc) < (nr)) \
alloc = (nr); \
else \
^ permalink raw reply related
* Re: Fix up ugly open-coded "alloc_nr()" user in object.c
From: Olivier Galibert @ 2007-06-16 22:15 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20070616182134.GA22003@coredump.intra.peff.net>
On Sat, Jun 16, 2007 at 02:21:34PM -0400, Jeff King wrote:
> How about using the new ALLOC_GROW macro to make it even shorter? I also
> got rid of the aliased variables, which IMO just make it harder to see
> what's going on.
> + ALLOC_GROW(array->objects, array->nr, array->alloc);
> + array->objects[array->nr].item = obj;
> + array->objects[array->nr].name = name;
> + array->objects[array->nr].mode = mode;
> + array->nr++;
Unless the ALLOC_GROW semantics are weird, shouldn't that be:
ALLOC_GROW(array->objects, array->nr+1, array->alloc);
OG.
^ 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