* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Jeff King @ 2009-01-30 16:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901301656290.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 04:58:25PM +0100, Johannes Schindelin wrote:
> > So either we don't care about http-push being consistent with send-pack,
> > and it is OK to have this feature in one but not the other. Or we do,
> > and we really need to clean up the current divergence.
>
> I do not see how your patch to send-pack makes that divergence any
> better, or for that matter, keeps it as bad as it is.
No, it makes it worse. My point was that I am not sure people actually
_care_ that much about the divergence.
> In other words, if you want to give the other protocols at least a
> _chance_ to catch up, you definitely need the support for push --track in
> builtin-push.c or at least in transport.c.
But neither of those places has the information to do it _right_. I
think the right thing to do is:
1. factor out "generic" routines from send-pack, including status
output formatting and tracking ref updating
2. refactor http-push to use those routines, bringing it in line with
send-pack
3. add --track support in the same generic way, and hook it from both
transports
I can try to work on this, but I'm not excited about major surgery to
http-push, which I don't have a working test setup for. I can't bring
myself to care about refactoring rsync, given the recent deprecation
discussion.
If it is going to be added to push or transport, then the transport API
needs refactoring to actually pass out information on what happened
(specifically, how we expanded the refspecs into matching ref pairs).
And maybe that is a more sensible long-term solution, but it is going
involve a lot of changes, too.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-30 16:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Pieter de Bie, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901301415260.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 02:18:32PM +0100, Johannes Schindelin wrote:
> > You could make a guess that they will use "master", and if you are
> > wrong, it behaves as now. But if you are right, "git pull" pulls down
> > master automatically.
> >
> > But that is getting a little confusing. So let's push this "git push
> > --track" idea to completion and see how people like it.
>
> How about installing
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> by default? It is a safe bet that this will be the case for 99% of all
> users that want to clone an empty repository (especially if they are
> putting their public repositories on something like repo.or.cz, where you
> cannot change the default branch from "master" to something else).
>
> And if somebody wants to track another branch, tough, she has to call
> this:
>
> $ git checkout -t origin/blablabla
I was tempted to suggest that, but I haven't thought through whether
there are any lurking corner cases (which empty clone seems to be
fraught with). So I think it is a reasonable thing to try and play with.
-Peff
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Jeff King @ 2009-01-30 16:28 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <76718490901300817x3f31460k59b6fe75d136372d@mail.gmail.com>
On Fri, Jan 30, 2009 at 11:17:49AM -0500, Jay Soffian wrote:
> I wonder if it might be helpful to teach clone to setup a push line in
> the cloned repo. i.e.:
>
> [remote "origin"]
> url = ...
> fetch = +refs/heads/*:refs/remotes/origin/*
> push = refs/heads/*:refs/remotes/origin/*
That refspec doesn't make sense, since the downstream is not the
"origin" to the upstream repo. But I don't think this is a good
solution; it is fundamentally changing the layout of pushed branches in
the upstream repo, which is going to cause a lot of confusion.
> This could be a configurable default behavior when cloning from a
> non-bare repo (can that be determined?) and/or as a switch
> (--satellite perhaps?).
I don't think you can tell whether a repo you are cloning is bare.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Charles Bailey @ 2009-01-30 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20090129091611.GB10490@hashpling.org>
On Thu, Jan 29, 2009 at 09:16:11AM +0000, Charles Bailey wrote:
> On Thu, Jan 29, 2009 at 12:26:39AM -0800, Junio C Hamano wrote:
> > Charles Bailey <charles@hashpling.org> writes:
> >
> > > On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> > >> * cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
> > >> + mergetool: respect autocrlf by using checkout-index
> > >>
> > >
> > > Can you hold off on merging this one? I now think that there's a
> > > cleaner way of doing this and I would like the opportunity for a
> > > rethink.
> >
> > Sure, it is not in 'master' yet.
> >
> > But it's in 'next', so incremental updates from now on, please.
> >
>
> OK, I've thought again and I still think that this patch is good.
Except that I was completely wrong. Please continue to hold off
merging into master until you've rolled in the future patch that fixes
mergetool in subdirectories which I'll clean-up and send later today.
Sorry about this.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Jeff King @ 2009-01-30 16:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901301423120.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 02:24:57PM +0100, Johannes Schindelin wrote:
> Let's reap all the opinions about this issue, and then I'll do the wrap-up
> patch.
I thought what Junio said was very reasonable (improve the message and
give it some more time to work).
But I honestly do not care that much either way. I probably would have
made the original patch default to "deny" if not for discussion
recommending to be conservative. On the other hand, I don't think we
have really given the "warning" approach enough time to see whether it
is working (and I don't necessarily disagree with your gut feeling that
it won't work; I am undecided, which leads me to want more data).
-Peff
^ permalink raw reply
* [ANNOUNCE] EasyGit (eg) 0.97
From: Elijah Newren @ 2009-01-30 16:42 UTC (permalink / raw)
To: Git Mailing List
=== What is Easy Git? ===
Easy Git (eg) is an alternative frontend for git, specifically designed for
former cvs and svn users in order to provide a lower learning curve and
prevent common user errors. Since eg largely looks and feels like core
git, eg can also serve as a training tool to teach users git (see below for
similarities and how to display git commands that eg uses). There is a
detailed side-by-side comparison of svn and eg to help svn users make the
switch[1]. eg is trivial to install and try out: simply download a single
file and stick it in your PATH[2].
=== How different is eg from git? ===
eg is nearly backward-compatible to the core git porcelain, meaning that
you can take any git command, replace "git" with "eg" and run it[3]; I
believe that any behavioral differences between eg and git can be
discovered naturally and innocuously by an existing git user during normal
use of eg. Also, you can switch back and forth between git and eg commands
in the same project. Finally, eg is also somewhat forward-compatible with
the git porcelain, by which I mean that new flags to git commands are often
supported automatically in eg even if no modifications are made to eg.
=== If eg is so similar, what is the difference between eg and git? ===
Differences between eg and git[4] basically boil down to:
* eg has a replacement help system that is tutorial oriented for new users
(these help pages do refer to the git manpages, for more in-depth details)
* eg does extra error checking to avoid some common gotchas
* eg changes some defaults, particularly where git defaults cause
significant confusion and/or common gotchas for users
* eg has some (occasionally gratuitous) new svn-compatibility subcommands
(cat, resolved, switch, update)
=== How far along is eg? ===
eg is essentially complete and has been for a while; I've used it daily
since last February, and there are multiple other users who do as well.
I've even benefitted from having some users who barely grasp the basics of
CVS who have tried eg and provided feedback ("[utterly broken workflow] is
what I do in CVS! To figure out how to do that in eg I had to go _read_
some of the help pages -- why can't you make it easy?")
eg has just one major bug left that I know of[5]; otherwise it's
essentially 1.0. eg requires fairly minimal maintainance -- most new
capabilities in git are automatically accessible through eg due to eg's
design of passing arguments on to git after optionally massaging them or
doing extra checks. In fact, this design also means eg users can benefit
from documentation meant for core git, and that eg users should often be
able to get help from git users without git users really needing to learn a
different UI. On the downside, this design also means that (a) eg feels
like an incomplete solution ("why does this message suggest running 'git
rebase --continue' when I'm using eg rather than git?"), and (b) eg's
interface is not simplified as much as it could be by focusing on a
specific use-case (e.g. centralized development) or providing a more
orthogonal UI[6]. It does, however, ease transition between the two tools
and potentially provide a testbed for ideas that could be adopted by git
more easily.
=== What's the path forward? ===
I have no idea. It turns out that eg allowed me to overcome the concerns
of others at work that "git was too difficult to use", and was an important
part of convincing them to switch to git instead of svn (we're stuck with
CVS right now but are working on switching). So eg won't die, unless git
itself adopts enough of the improvements in eg. And really, some stuff
from eg may just not belong in git, so it may make sense to have an
independent script indefinitely (though it could certainly be made much
smaller).
What makes sense to the community? Some possibilities:
* Keep working on eg completely independently
* Propose eg (and perhaps eg-completion.bash) for contrib
* Start a series of discussions on individual changes from eg and see which
ones the community thinks make sense in git
* Have me stop being lazy and create patches for git as a basis of
discussion
* Let the crickets chirp (i.e. just ignore this weird Easy Git guy)
* Some combination of the above, or maybe something else entirely?
Elijah
[1] http://www.gnome.org/~newren/eg/git-for-svn-users.html
[2] http://www.gnome.org/~newren/eg/download, or
[3] If you're curious if/how/when eg changes arguments before passing them
to git, you can run "eg --debug ARGS..." to see the git commands eg is
running. If you just want to see the git commands that eg would run
without them also being executed, you can run "eg --translate ARGS..."
[4] For detailed differences, see
http://www.gnome.org/~newren/eg/git-eg-differences.html
[5] The bug I can only occasionally trigger and which I don't know the
cause of yet: when exiting from eg log the terminal settings sometimes
are messed up (with echo off and such), requiring a "reset" to get the
terminal back to normal.
[6] http://marc.info/?l=git&m=122071366316713&w=1
^ permalink raw reply
* Re: [PATCH 1/2] fsck: HEAD is part of refs
From: Johannes Schindelin @ 2009-01-30 16:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, H. Peter Anvin, Ingo Molnar, Git Mailing List
In-Reply-To: <7veiylb1in.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Fri, 30 Jan 2009, Junio C Hamano wrote:
> By default we looked at all refs but not HEAD. The only thing that
> made fsck not lose sight of comments that are only reachable from a
> detached HEAD was the reflog for the HEAD.
When fixing the revision machinery to imply HEAD with --all, I thought of
fsck, too, but forgot to check if it does actually use the revision
walker.
Sorry about this,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 16:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090130163317.GB6963@sigill.intra.peff.net>
Hi,
On Fri, 30 Jan 2009, Jeff King wrote:
> On Fri, Jan 30, 2009 at 02:24:57PM +0100, Johannes Schindelin wrote:
>
> > Let's reap all the opinions about this issue, and then I'll do the
> > wrap-up patch.
>
> I thought what Junio said was very reasonable (improve the message and
> give it some more time to work).
>
> But I honestly do not care that much either way. I probably would have
> made the original patch default to "deny" if not for discussion
> recommending to be conservative. On the other hand, I don't think we
> have really given the "warning" approach enough time to see whether it
> is working (and I don't necessarily disagree with your gut feeling that
> it won't work; I am undecided, which leads me to want more data).
It is not working:
http://groups.google.com/group/msysgit/msg/55b1aa03fbbbefba?dmode=source
(I am simply assuming that the mentioned 1.6.1-preview has the
warning, since denyCurrentBranch is in v1.6.1-rc1~59^2, and I am too short
on time to check it in detail (which would mean finding a Windows machine
and running a test)).
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Mike Ralphson @ 2009-01-30 16:59 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List, Jeff King
In-Reply-To: <51419b2c0901300842rb993454u7e8b6d1032c12ac8@mail.gmail.com>
2009/1/30 Elijah Newren <newren@gmail.com>:
> [5] The bug I can only occasionally trigger and which I don't know the
> cause of yet: when exiting from eg log the terminal settings sometimes
> are messed up (with echo off and such), requiring a "reset" to get the
> terminal back to normal.
Are you sure that isn't this bug in git.git ?
pager: do wait_for_pager on signal death
http://article.gmane.org/gmane.comp.version-control.git/106728
Mike
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 17:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster
In-Reply-To: <76718490901300817x3f31460k59b6fe75d136372d@mail.gmail.com>
Hi,
On Fri, 30 Jan 2009, Jay Soffian wrote:
> On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> > Many, many users set up non-bare repositories on their server, and are
> > confused that the working directory is not updated.
>
> This comes up on the list from time-to-time and is even in the FAQ.
So much so that it is high time we admitted that we have a design bug
there.
> It has even been suggested that HEAD be detached when pushing into a
> non-bare repository, but I am not suggesting that again.
No, because that would be as wrong as trying to update the working
directory in any other way. (Not only is it possible that you are a
git-shell user, in which case you have no business meddling with the
working directory -- or the symbolic ref HEAD -- to begin with, but you
also run into the problem that you might not know where the working
directory is at all, let alone if there is one.)
So it is a good thing you are not suggesting it again.
> I wonder if it might be helpful to teach clone to setup a push line in
> the cloned repo. i.e.:
>
> [remote "origin"]
> url = ...
> fetch = +refs/heads/*:refs/remotes/origin/*
> push = refs/heads/*:refs/remotes/origin/*
>
> This could be a configurable default behavior when cloning from a
> non-bare repo (can that be determined?) and/or as a switch
> (--satellite perhaps?).
As Peff commented, this would be horribly wrong if the remote has a
different "origin" remote. Not forcing the push does not help either, it
is still wrong.
But I think there is an even more fundamental problem: You do not want
that default push. We have "push only those refs the remote and the local
repository share" rule for a reason. It is way too easy to publish
something you did not mean to publish otherwise.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Johannes Schindelin @ 2009-01-30 17:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20090130162258.GA7065@sigill.intra.peff.net>
Hi,
On Fri, 30 Jan 2009, Jeff King wrote:
> I think the right thing to do is:
>
> 1. factor out "generic" routines from send-pack, including status
> output formatting and tracking ref updating
>
> 2. refactor http-push to use those routines, bringing it in line with
> send-pack
>
> 3. add --track support in the same generic way, and hook it from both
> transports
Now we're thinking along the same lines!
> I can try to work on this, but I'm not excited about major surgery to
> http-push, which I don't have a working test setup for.
You don't have an apache installed?
> I can't bring myself to care about refactoring rsync, given the recent
> deprecation discussion.
Don't do it, then.
> If it is going to be added to push or transport, then the transport API
> needs refactoring to actually pass out information on what happened
> (specifically, how we expanded the refspecs into matching ref pairs).
> And maybe that is a more sensible long-term solution, but it is going
> involve a lot of changes, too.
I think that the --track should just be passed to the transport API, which
should call the necessary git_config thing itself upon successful push.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Johannes Schindelin @ 2009-01-30 17:12 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git
In-Reply-To: <1233308489-2656-2-git-send-email-geofft@mit.edu>
Hi,
On Fri, 30 Jan 2009, Geoffrey Thomas wrote:
> From: Geoffrey Thomas <geofft@mit.edu>
> git blame misaligns output if a author's name has a differing display width and
> strlen; for instance, an accented Latin letter that takes two bytes to encode
> will cause the rest of the line to be shifted to the left by one. To fix this,
> use utf8_strwidth instead of strlen (and compute the padding ourselves, since
> printf doesn't know about UTF-8).
Good point (even if your commit message has lines much longer than 72
chars, ASCII ones at that).
But how certain are you at that point that the authors are in UTF-8
format? IOW what encoding conversions were possibly performed up to that
point?
You might want to make it easier on possible reviewers by putting that
discussion into the commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH --no-flowed] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-30 17:17 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <49831755.60405@gmail.com>
Hi,
On Fri, 30 Jan 2009, Tay Ray Chuan wrote:
> +static void append_remote_object_url(struct strbuf *buf, const char *url, const char *hex, int only_two_digit_prefix)
I seem to remember that I mentioned that this line is too long.
Ciao,
Dscho
^ permalink raw reply
* Re: Git log can not show history before rename
From: Linus Torvalds @ 2009-01-30 17:17 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901300429i6d9b3594m91222314c284d184@mail.gmail.com>
On Fri, 30 Jan 2009, Frank Li wrote:
>
> Does it conflict with --parents?
Yes. --follow and --parents do not play well together.
That's simply because --follow is a total hack, meant to just satisfy
ex-SVN users who never knew anything about things like parenthood or nice
revision graphs anyway.
It's not totally fundamental, but the current implementation of "--follow"
is really a quick preprocessing thing bolted onto the revision walking
logic, rather than beign anything really integral.
If you want --follow to really work together with --parents (and to do the
right thing wrt merges etc - different renames coming in through different
branches), you'd really have to rewrite the whole --follow logic.
One approach is to use --follow as the quick hack it is - and then when
you see "oh, file X was renamed from file Y", and you want to see the nice
full history, you go back to the native git model (which is not --follow),
which is based on pathname pattherns, and then do
gitk -- X Y
to see the history of _both_ names, and now the rename will show up
properly (and now you'll get proper parenthood because you're no longer
using the hackish --follow thing).
If somebody wants to do a more intelligent --follow, I can only applaud,
but I'm personally not likely to look into it.
Linus
^ permalink raw reply
* Re: Git log can not show history before rename
From: Linus Torvalds @ 2009-01-30 17:23 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0901300910580.3150@localhost.localdomain>
On Fri, 30 Jan 2009, Linus Torvalds wrote:
>
> If somebody wants to do a more intelligent --follow, I can only applaud,
> but I'm personally not likely to look into it.
Side note: you can probably get a _limited_ form of parent rewriting on
top of --follow by adding some more hacks. IOW, I think you can make
--parents --follow work better in practice even with the hacky thing by
adding some more hacks on top. But you'll never get the _true_ answer (ie
get things right across renames in different branches) without totally
ripping out the current --follow logic.
Interestingly, I suspect that doing --follow "right" is really quite
complicated, but one sign of doing it right would be to allow multiple
files to be tracked at the same time.
Because in a "correct" implementation of --follow you'd literally have to
attach different filenames to different commits (rather than have one
global filename that you follow and then switch for everybody when you see
a rename), and also have the ability to track multiple files per commit
when you reach the same commit under two filenames.
I really never wanted the pain, and never cared enough for it, which is
why --follow is such a hack. It literally was designed as a "SVN noob"
pleaser, not as a "real git functionality" thing. The idea was that you'd
get away from the (broken) mindset of thinking that renames matter in the
big picture.
Linus
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Sitaram Chamarty @ 2009-01-30 17:31 UTC (permalink / raw)
To: git
In-Reply-To: <871vulda2r.fsf@gigli.quasi.internal>
[replying only because no one else did; caveat reader!]
On 2009-01-29, Raimund Berger <raimund.berger@gmail.com> wrote:
> The question is whether a (3way) merge is commutative, purely in terms
> of content (i.e. disregarding commit history for now). Iow if no matter
> in which order I merge A and B, i.e. A into B or B into A, I'd be
> guaranteed to arrive at the same content.
I'd say yes. Finding the common ancestor and then applying
the differences from both sides are operations that do not
appear to be order dependent.
> If yes, a followup question would be if the merge machinery sitting
> beneath rebase is exactly the same as that of a standard merge.
The merge "machinery" can be explicitly chosen using the
"-s" (strategy) option, but for the same chosen strategy, I
think yes it would be the same for a merge as for a rebase.
> The reason I ask is obvious I guess. What basically interests me is if I
> gave a bunch of topic branches exposure on a test branch and, after
> resolving issues, applied them to stable, that I could be 100% sure to
> not introduce new issues content wise just by applying merges in a
> different order or form (rebase, patch set).
That appears to be a different question than the one you
started with.
Reversing A and B is one thing, applying a sequence of
merges in a different order is quite something else.
^ permalink raw reply
* Re: [StGit PATCH] Check for local changes with "goto"
From: Catalin Marinas @ 2009-01-30 17:36 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090130152649.GA22044@diana.vm.bytemark.co.uk>
2009/1/30 Karl Hasselström <kha@treskal.com>:
> On 2009-01-30 14:01:20 +0000, Catalin Marinas wrote:
>
>> @@ -706,9 +706,15 @@ class Index(RunWithEnv):
>> ).output_one_line())
>> except run.RunException:
>> raise MergeException('Conflicting merge')
>> - def is_clean(self):
>> + def is_clean(self, tree = None):
>> + """Check whether the index is clean relative to the given tree."""
>> + if tree:
>> + sha1 = tree.sha1
>> + else:
>> + sha1 = 'HEAD'
>> try:
>> - self.run(['git', 'update-index', '--refresh']).discard_output()
>> + self.run(['git', 'diff-index', '--quiet', '--cached', sha1]
>> + ).discard_output()
>> except run.RunException:
>> return False
>> else:
>
> OK (though I personally would have allowed only Tree objects, with no
> defaulting to the current HEAD).
Done.
See below for an update. I added an __assert_index_worktree_clean()
function in Transaction.
Now, should we add the check_clean argument to Transaction.__init__()
rather than run() as we do for the allow_bad_head case? The check
would need to be done in run() where we have an iw. Just a thought,
I'm not convinced it is better.
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index e2b4266..07079b8 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -706,9 +706,11 @@ class Index(RunWithEnv):
).output_one_line())
except run.RunException:
raise MergeException('Conflicting merge')
- def is_clean(self):
+ def is_clean(self, tree):
+ """Check whether the index is clean relative to the given treeish."""
try:
- self.run(['git', 'update-index', '--refresh']).discard_output()
+ self.run(['git', 'diff-index', '--quiet', '--cached', tree.sha1]
+ ).discard_output()
except run.RunException:
return False
else:
@@ -858,6 +860,14 @@ class IndexAndWorktree(RunWithEnvCwd):
cmd = ['git', 'update-index', '--remove']
self.run(cmd + ['-z', '--stdin']
).input_nulterm(paths).discard_output()
+ def worktree_clean(self):
+ """Check whether the worktree is clean relative to index."""
+ try:
+ self.run(['git', 'update-index', '--refresh']).discard_output()
+ except run.RunException:
+ return False
+ else:
+ return True
class Branch(object):
"""Represents a Git branch."""
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 54de127..c961222 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -147,6 +147,11 @@ class StackTransaction(object):
'This can happen if you modify a branch with git.',
'"stg repair --help" explains more about what to do next.')
self.__abort()
+ def __assert_index_worktree_clean(self, iw):
+ if not iw.worktree_clean() or \
+ not iw.index.is_clean(self.stack.head.data.tree):
+ self.__halt('Repository not clean. Use "refresh" or '
+ '"status --reset"')
def __checkout(self, tree, iw, allow_bad_head):
if not allow_bad_head:
self.__assert_head_top_equal()
@@ -183,13 +188,17 @@ class StackTransaction(object):
self.__checkout(self.__stack.head.data.tree, iw,
allow_bad_head = True)
def run(self, iw = None, set_head = True, allow_bad_head = False,
- print_current_patch = True):
+ print_current_patch = True, check_clean = False):
"""Execute the transaction. Will either succeed, or fail (with an
exception) and do nothing."""
self.__check_consistency()
log.log_external_mods(self.__stack)
new_head = self.head
+ # Check for clean index and worktree
+ if check_clean and iw:
+ self.__assert_index_worktree_clean(iw)
+
# Set branch head.
if set_head:
if iw:
--
Catalin
^ permalink raw reply related
* .gitconfig permissions
From: Andrey Borzenkov @ 2009-01-30 17:41 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
I was setting StGIT options to send mail; I need SMTP authentication so
I'd like to set password to avoid typing it every time. After setting
options I checked and ~/.gitconfig was created with 664 permissions.
Given it may contain sensitive options, would not 600 default be better?
Thank you!
-andrey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Bus Error- git merge
From: Brian Moran @ 2009-01-30 18:15 UTC (permalink / raw)
To: git@vger.kernel.org
I am getting a bus error on a git merge, including the more recent versions.
Following the instructions from a bug August, I got the latest sources,
compiled them up, and executed the merge in the debugger to repro. Here¹s
what I found:
gdb ../git-1.6.1.2/git-merge
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC
2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries ........ done
(gdb) set args -v v1-ftp-support
(gdb) run
Starting program: /Users/bmo/Documents/repo/git-1.6.1.2/git-merge -v
v1-ftp-support
Reading symbols for shared libraries +++++++. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
0x000863c3 in sha_eq (a=0x4 <Address 0x4 out of bounds>, b=0x7bf004 "<some
random chars>") at cache.h:575
575 return memcmp(sha1, sha2, 20);
(gdb) backtrace
#0 0x000863c3 in sha_eq (a=0x4 <Address 0x4 out of bounds>, b=0x7bf004
"<some random chars>") at cache.h:575
#1 0x00086dc6 in merge_trees (o=0xbfffedd4, head=0x7bf020, merge=0x7bf000,
common=0x0, result=0xbfffed28) at merge-recursive.c:1164
#2 0x00088960 in merge_recursive (o=0xbfffedd4, h1=0x4f4060, h2=0x4f4000,
ca=0x53cc20, result=0xbfffee2c) at merge-recursive.c:1294
#3 0x0003871c in try_merge_strategy (strategy=0xd28ce "recursive",
common=0x53a040, head_arg=0xc3508 "HEAD") at builtin-merge.c:586
#4 0x00039fef in cmd_merge (argc=1, argv=0xbffff860, prefix=0x0) at
builtin-merge.c:1131
#5 0x000025db in handle_internal_command (argc=3, argv=0xbffff860) at
git.c:243
#6 0x00002c48 in main (argc=3, argv=0xbffff860) at git.c:453
(gdb)
Any suggestions on how to proceed? I am available to gather more information
on this as I can reproduce at will.
Thanks,
Brian Moran
http://www.onehub.com
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Elijah Newren @ 2009-01-30 18:35 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Git Mailing List, Jeff King
In-Reply-To: <e2b179460901300859r438a4230hc990305688b4f29e@mail.gmail.com>
On Fri, Jan 30, 2009 at 9:59 AM, Mike Ralphson <mike.ralphson@gmail.com> wrote:
> 2009/1/30 Elijah Newren <newren@gmail.com>:
>> [5] The bug I can only occasionally trigger and which I don't know the
>> cause of yet: when exiting from eg log the terminal settings sometimes
>> are messed up (with echo off and such), requiring a "reset" to get the
>> terminal back to normal.
>
> Are you sure that isn't this bug in git.git ?
>
> pager: do wait_for_pager on signal death
> http://article.gmane.org/gmane.comp.version-control.git/106728
Interesting. I just went and tried out next (git version
1.6.1.2.418.gd79e6), which I believe has this patch...and after a
while I was still able to duplicate the eg bug on one of my
machines[1]. So it doesn't seem to be that particular issue, at
least.
Thanks for the pointer.
Elijah
[1] Output of stty after I trigger the eg/git bug:
speed 38400 baud; line=0;
lnext = <undef>; min = 1; time = 0;
-icrnl
-icanon -echo
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Jay Soffian @ 2009-01-30 18:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901301756560.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> As Peff commented, this would be horribly wrong if the remote has a
> different "origin" remote. Not forcing the push does not help either, it
> is still wrong.
Got it. Here was my impression of the work-flow we're trying to help
beginners with:
machineA$ mkdir repo
machineA$ cd repo
machineA$ git init
machineA$ add, commit, add, commit...
machineB$ git clone ssh://machine1/repo
machineB$ add, commit, add, commit...
machineB$ git push
(And if my impression is wrong, then stop me right here and I'll
shut-up on this thread.)
In this case, the clone operation sets up the repo on B to fetch all
of the branches from the repo on A. But it doesn't do anything to help
the user with pushing the repo from B back to machine A. So perhaps:
git clone --origin machineA --push-as machineB ssh://machineA/repo
[remote "machineA"]
url = ...
fetch = +refs/heads/*:refs/remotes/machineA/*
push = +refs/heads/*:refs/remotes/machineB/*
Now fetch and push are symmetric operations on machineB.
> But I think there is an even more fundamental problem: You do not want
> that default push. We have "push only those refs the remote and the local
> repository share" rule for a reason. It is way too easy to publish
> something you did not mean to publish otherwise.
I don't have a good answer for that, other than to say that if user is
setting up symmetric repositories, user wants to push everything.
j.
^ permalink raw reply
* Re: Bus Error- git merge
From: Johannes Schindelin @ 2009-01-30 18:57 UTC (permalink / raw)
To: Brian Moran; +Cc: git@vger.kernel.org
In-Reply-To: <C5A883D0.E243%bmoran@onehub.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2205 bytes --]
Hi,
On Fri, 30 Jan 2009, Brian Moran wrote:
> I am getting a bus error on a git merge, including the more recent versions.
> Following the instructions from a bug August, I got the latest sources,
> compiled them up, and executed the merge in the debugger to repro. Here¹s
> what I found:
Is it possible that your branch has submodules?
> gdb ../git-1.6.1.2/git-merge
> GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC
> 2007)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
> libraries ........ done
>
> (gdb) set args -v v1-ftp-support
> (gdb) run
> Starting program: /Users/bmo/Documents/repo/git-1.6.1.2/git-merge -v
> v1-ftp-support
> Reading symbols for shared libraries +++++++. done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
> 0x000863c3 in sha_eq (a=0x4 <Address 0x4 out of bounds>, b=0x7bf004 "<some
> random chars>") at cache.h:575
> 575 return memcmp(sha1, sha2, 20);
>
> (gdb) backtrace
> #0 0x000863c3 in sha_eq (a=0x4 <Address 0x4 out of bounds>, b=0x7bf004
> "<some random chars>") at cache.h:575
> #1 0x00086dc6 in merge_trees (o=0xbfffedd4, head=0x7bf020, merge=0x7bf000,
> common=0x0, result=0xbfffed28) at merge-recursive.c:1164
common=0x0, that's the issue.
> #2 0x00088960 in merge_recursive (o=0xbfffedd4, h1=0x4f4060, h2=0x4f4000,
> ca=0x53cc20, result=0xbfffee2c) at merge-recursive.c:1294
However, here I read in my version of merge-recursive.c that "common" is
the tree of merged_common_ancestor, which is either set to
"pop_commit(&ca)", i.e. to one of the common ancestors, or to a virtual
commit, that must have a tree.
So it would be good if you could debug this further, letting me know where
the merged_common_ancestor came from, and why it does not have a tree.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-01-30 19:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster
In-Reply-To: <76718490901301050h1f0f5b2bq902de384d954d99b@mail.gmail.com>
Hi,
On Fri, 30 Jan 2009, Jay Soffian wrote:
> On Fri, Jan 30, 2009 at 12:01 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > As Peff commented, this would be horribly wrong if the remote has a
> > different "origin" remote. Not forcing the push does not help either,
> > it is still wrong.
>
> Got it. Here was my impression of the work-flow we're trying to help
> beginners with:
>
> machineA$ mkdir repo
> machineA$ cd repo
> machineA$ git init
> machineA$ add, commit, add, commit...
>
> machineB$ git clone ssh://machine1/repo
> machineB$ add, commit, add, commit...
> machineB$ git push
>
> (And if my impression is wrong, then stop me right here and I'll
> shut-up on this thread.)
I think your impression is not wrong.
BUT.
You cannot just cater for one workflow and fsck the other workflows over.
You'll have to devise a method that helps the workflow you are interested
in, but leaves the others alone.
Example: the thing I heard most often was "I want to start this
repository, but there is nothing in there yet, yet I want other people to
clone it already so they'll see something when I do."
I admit, it does not strike me sensible, but so does cloning an empty
repository. As I could not understand how people would want to vote for
Bush. Yet they did, so I guess I'll have to live with it.
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Raimund Berger @ 2009-01-30 19:09 UTC (permalink / raw)
To: git
In-Reply-To: <slrngo6eat.s1d.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> [replying only because no one else did; caveat reader!]
>
> On 2009-01-29, Raimund Berger <raimund.berger@gmail.com> wrote:
>
>> The question is whether a (3way) merge is commutative, purely in terms
>> of content (i.e. disregarding commit history for now). Iow if no matter
>> in which order I merge A and B, i.e. A into B or B into A, I'd be
>> guaranteed to arrive at the same content.
>
> I'd say yes. Finding the common ancestor and then applying
> the differences from both sides are operations that do not
> appear to be order dependent.
That's exactly the point which I'd like to have clarified.
E.g. with A, B and ancestor C, the merging and conflict resolution
algorithm had to be completely symmetric if diff(A,C)+diff(B,C) applied
to C should always be the same as diff(B,C)+diff(A,C) applied to C.
So I'm really asking if that is a fact upon which I can rely.
>
>> If yes, a followup question would be if the merge machinery sitting
>> beneath rebase is exactly the same as that of a standard merge.
>
> The merge "machinery" can be explicitly chosen using the
> "-s" (strategy) option, but for the same chosen strategy, I
> think yes it would be the same for a merge as for a rebase.
An interesting hint. Up to now, I assumed that rebase would always
perform implicit merging strategies. I mean what else would one expect
in the above picture to happen when rebasing A on B? I'd assume it'd
produce the same tree as a merge of A into B, by employing exactly the
same machinery. E.g. fast forward of C to B, then merge A in. So that,
effectively, the only difference between rebase and merge is just commit
history but not (tree) content.
>From reading the rebase man page though it seems that merging machinery
has to be explicitly requested via '-m'. Which makes me wonder how the
default rebase actually works.
>
>> The reason I ask is obvious I guess. What basically interests me is if I
>> gave a bunch of topic branches exposure on a test branch and, after
>> resolving issues, applied them to stable, that I could be 100% sure to
>> not introduce new issues content wise just by applying merges in a
>> different order or form (rebase, patch set).
>
> That appears to be a different question than the one you
> started with.
>
> Reversing A and B is one thing, applying a sequence of
> merges in a different order is quite something else.
Mathematically speaking, if A1 and A2 commute with regard to a binary
operation, A1 ... An do as well. So I'd still think the latter question
boils down to the commutativity question above *iff* rebase actually
does an implicit merge by default. Which I'm now led to question.
Thanks for you answer, much appreciated.
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Jeff King @ 2009-01-30 19:47 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <51419b2c0901301035g6867b9d8l2d4de9590035bd4e@mail.gmail.com>
On Fri, Jan 30, 2009 at 11:35:50AM -0700, Elijah Newren wrote:
> > 2009/1/30 Elijah Newren <newren@gmail.com>:
> >> [5] The bug I can only occasionally trigger and which I don't know the
> >> cause of yet: when exiting from eg log the terminal settings sometimes
> >> are messed up (with echo off and such), requiring a "reset" to get the
> >> terminal back to normal.
> >
> > Are you sure that isn't this bug in git.git ?
> >
> > pager: do wait_for_pager on signal death
> > http://article.gmane.org/gmane.comp.version-control.git/106728
>
> Interesting. I just went and tried out next (git version
> 1.6.1.2.418.gd79e6), which I believe has this patch...and after a
> while I was still able to duplicate the eg bug on one of my
> machines[1]. So it doesn't seem to be that particular issue, at
> least.
There is also a related set of fixes for spawning externals via fork,
which fixes a bug with the pager not getting cleaned up. But it looks
like it is also in the version you tested.
Can you give a more complete recipe for reproducing? Since I was just
touching this area in git, I want to make sure it isn't a git bug you
are triggering. :)
As an aside, I found some related weirdness. In my git repo, if I do
this:
$ git checkout next
$ eg log -p
I get log output, but the diff is not colorized (and I have color.diff
set to "auto" in my ~/.gitconfig). But if I detach my HEAD and show the
log:
$ git checkout next^0
$ eg log -p
then I _do_ get color in the patch. I also get this error:
Use of uninitialized value $branch in concatenation (.) or string at
/home/peff/eg line 2854.
eg: command (git rev-parse refs/heads/) failed
eg: received signal 13
The error is easy to explain. The offending code is:
my $branch = RepoUtil::current_branch();
my ($ret, $revision) =
ExecUtil::execute_captured("git rev-parse refs/heads/$branch");
So it is clear that you just need to handle the case of there being no
current branch. But the color thing is certainly exotic. :)
-Peff
^ 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