* Re: git submodules and commit
From: Avery Pennarun @ 2008-07-17 15:12 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170247g7bb18252ma50b202e1d762296@mail.gmail.com>
On 7/17/08, Nigel Magnay <nigel.magnay@gmail.com> wrote:
> Yeah - this happens a lot. If someone else commits to the
> super-project before you, it's always a conflict. What's annoying is
> there's no way around it (though resolution is easy - force to current
> - but it this is a big bit of what confuses my users. They say 'but I
> already resolved the merges in the submodule itself'. I'm not sure
> there's an easy way around it though - and this is part of my worry
> that there's hidden complexity with trying to make it 'look like 1 big
> repo').
This might not be as hard as it sounds. We probably just need to
teach the supermodule how to merge gitlinks safely. So basically, if
I moved the gitlink from A to B, and he moved it from A to C, then it
needs to check whether a fast forward merge already exists for the
submodule to combine B and C. This is easier than it sounds, because
if I *already* ran my newest-git-modules script in the inner module,
then I've already manually resolved the merge in question, so that B
*does* actually contain C.
Right now, such a thing results in a conflict. It isn't really a
conflict though, it's a fast forward, and the supermodule's merge
should ideally just notice that and run with it.
Sadly I know very little about the merge code. But I would be happy
to help you test a patch that implemented this :)
A slightly more advanced version of the same would automatically walk
into the submodule and ask it to merge B and C. I suspect that is way
more complicated than it sounds at first glance, though (particularly
if the new B or C gitlink doesn't have A as a parent at all, which
couldn't happen in a unified git repo, but is perfectly allowable with
submodules).
With anything like this, there's always the question of what happens
if you haven't done a "fetch" in the submodule yet; I think reverting
to the current behaviour is fine in that case, because I can make
newest-git-modules to always fetch before trying anything anyway.
> Yeah. I have an additional usecase, which is around pulling from
> another user. If they've made changes in their tree(s) that they want
> to get reviewed, normally I could do something like
>
> git fetch ssh://joebloggs.computer/blah +refs/heads/*:refs/remotes/joebloggs/*
>
> But if they've made cross-module changes, I'm SOL, as fetching their
> super-project will have references to commits that aren't in the repo
> mentioned in .gitmodules (only in joebloggs's tree) - so doing git
> submodule update doesn't help. I have to go into each submodule and
> explicitly fetch. It feels wierdly centralised for this otherwise
> distributed tool.
One slightly non-obvious option here is to actually use the *same*
repo for all your supermodules and submodules, then use "." as the
repo path in your .gitmodules. The original clone is huge that way,
but it makes it obvious how to get any objects that you're missing.
Then you could construct your submodules using --reference the
supermodule. Thus, doing a "fetch" of your user's supermodule, you'll
also get all the objects it references.
Note that I've only basically tried out this technique. I think it's
the one for me, but I haven't experimented with it enough to know any
pitfalls. When I've brought it up on the list, it's been shot down
because it wouldn't work for gigantic mega-repositories like KDE where
the whole point of submodules is to *not* download all the modules
every time. It works for me, though, because my software doesn't even
*build* unless I have all the modules.
(And before anyone asks, yes, it still makes sense to use submodules
because some of the modules are shared with other projects.)
> What's bugging me is I'm not sure that it's the right place. It seems
> (to me) that having the only place that knows about submodules being
> the 'git submodules' script isn't right. What users want is 'git fetch
> <blah>' to do the lot - that, for the most, it ought to do the
> submodule init, update and clever stuff automatically. That if 'git
> fetch' is porcelain, then the porcelain needs to call the
> git-submodule stuff.
There is some architectural elegance to the fact that the gitlink
stuff is almost completely abstract (just a number, really) in the
core of git, and is only made "real" by running git-submodule, which
actually extracts files and makes .git dirs and fetches submodules and
whatnot.
However, it's architectural elegance, not UI elegance. As a user, I
mostly don't want to have to care whether a particular directory is a
"submodule" or not, so the extra push and commit and fetch steps
become tedious. From the point of view of UI, I agree with you.
Perhaps this is a plumbing vs. porcelain issue. I don't think
git-submodule has made an attempt to separate the two, since it seems
to be porcelain, but there's no "submodule plumbing" underneath
(AFAICS) that things like git-fetch and git-commit and git-push can
plug into.
> But - perhaps it's best to approach it as scripts for now :)
I suspect so :)
> Hm - I'd be happy with the same commt message in all modules. What I
> want is to be able to do (from the top) 'git commit -a' or the same
> with the GUI, and see all the files to be committed regardless of
> whether they're in a submodule or not.
That actually wouldn't work very well for me. I do need the commits
separated, because that's why I'm using submodules in the first place
instead of the "subtree" merge strategy.
Basically, I'm still planning on contributing patches to my class
library upstream, and the patches need to talk about how they affect
the *library*, not what I changed in my application. So I *would*
want to write separate commit messages in all cases. I can see how
other people might not, though.
> This is what the users want - something that mirrors 'svn ci' at the
> top level - "Please Check All My stuff in".
Note that submodules are more like svn:externals, which also require
you to commit each module separately. One big difference there is
that you don't need to commit to the supermodule each time you commit
to the submodule, but that's only because svn:externals by default
links to a branch, not to a particular revision. The
revision-specific linking is very worthwhile, I think, so requiring an
extra commit is mostly okay here.
Perhaps automating the extra commit would be nice in some cases, but
for me, for example, I tend to combine my "update to newest version of
submodule" commit with some changes to the supermodule, since the
reason I updated was to implement this new feature.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 15:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807171513560.8986@racer>
On Thu, Jul 17, 2008 at 3:16 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> Your attitude seems to be that the status-quo is in some way desirable;
>> "It's no wonder that this tool is awkward to use in your workflow.".
>> This workflow is really common, and there's actual, real people on this
>> list complaining about it. Don't we think it could be improved to be
>> non-awkward ?
>
> I do not think that the status quo is the best possible.
>
> But I think that the way you go makes things so confusing that those who
> use it apart from you will have problems.
>
Ok
> For example, in your setup everybody would have to install _different_
> remotes in every submodule.
>
> And then some would ask themselves why the original origin was not good
> enough.
>
> And others would specify "-o origin" all the time, thinking it was
> required.
>
> There must be a better way to promote submodules to a usable state,
My attempt was to try and do some small simple things, but you could
well be right, that might make some commands bloat out with
unneccessary options just to get something done, and that would be
bad.
Stepping back - lets try to come up with a better way (please comment
and and critique)
What we'd like (to start with) is for
$ git pull fred
perhaps with --submodules (as Petr mentions), perhaps with config
settings and caveats, to produce a result that means you don't need to
be aware that there were submodules, they're automatically fetched and
updated based on commits that may only exist in fred's repository.
So currently, you can do
$ git pull origin && git submodule init && git submodule update
And it works, but
$ git pull fred
$ git submodule update
Can leave you with problems, because if a submodule wasn't pushed to
origin, you won't have it available. This is because the commands are
equivalent to
$ git pull fred
for each submodule()
cd submodule
git fetch origin
git checkout <sha1>
So somehow, you need to replace 'git fetch origin' with the "correct"
repository (on fred's computer). My patch was really just about being
able to pass parameters to 'git fetch'. The problems are that if you
did
$ git submodule update fred
Unless each submodule had a [remote] specified for "fred", you'd be
stuffed. But what you could do is either by passing the right URL, or
looking at the superproject [remote] for "fred" - i.e: If in the
superproject you have
[remote "fred"]
url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
[submodule "module"]
url = ssh://git@repo/pub/scm/git/module.git
Then the submodule "module" on fred, if it's a working-copy, can be calculated
ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git
If it isn't a WC then you'd have to have a [remote "fred"] in that
submodule, but I'm thinking that'd be a rare case.
I'd assumed (possibly wrongly?) that there was resistance to putting
any of the submodule logic in things other than git-submodules.
As a starter for 10, how about
- a '--submodules' option to git fetch / pull
- using the remote name if known, calculate it if not based on the above
WDYT?
^ permalink raw reply
* Re: Contributors, please check your names
From: Nicolas Pitre @ 2008-07-17 14:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3sku8sh01.fsf@localhost.localdomain>
On Thu, 17 Jul 2008, Jakub Narebski wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > There is a "mailmap" mechanism to consolidate them; it allows us to
> > specify what human-readable name should be used for given e-mail address.
> > The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
> > from me, <author@example.xz>, are marked without abbreviating periods in
> > my name", and we can add this entry to the toplevel .mailmap file to fix
> > it:
> >
> > A. U. Thor <author@example.xz>
> >
> > It tells the shortlog (and --pretty=format:%aN in recent enough git)
> > mechanism to give huma readable name "A. U. Thor" anytime it sees
> > <author@example.xz> e-mail address, regardless of what the Author:
> > header in the commit object says.
>
> What about if some authors use different _email_ address, instead?
> Is there any way for shortlog to consider them the same?
It already does, unless you use the -e switch.
Nicolas
^ permalink raw reply
* Re: [PATCH] guilt(1): fix path to git-sh-setup
From: Josef 'Jeff' Sipek @ 2008-07-17 14:53 UTC (permalink / raw)
To: Alex Chiang, git
In-Reply-To: <20080716232339.GC22919@ldl.fc.hp.com>
On Wed, Jul 16, 2008 at 05:23:39PM -0600, Alex Chiang wrote:
> git is in the process of moving subcommands to /usr/libexec/git-core
>
> This move breaks an assumption in guilt about the location of
> git-sh-setup.
I already have a fix for this queued up.
Thanks anyway,
Josef 'Jeff' Sipek.
P.S. Pasky: good catch, I'll check the queued up patch to make sure it's not
"broken"
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Petr Baudis @ 2008-07-17 14:51 UTC (permalink / raw)
To: Craig L. Ching; +Cc: Johannes Schindelin, Avery Pennarun, Junio C Hamano, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A144@emailmn.mqsoftware.com>
On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:
> Maybe if Git had a few different workflows
> documented that might help. I know we have a "Git for SVN Users"
> workflow, but if you want to move beyond that, it might be good to have
> some of the more complex workflows documented. I think some people have
> hinted at that suggestion but that maybe it just hasn't been explicitly
> said.
Yes, very recently, someone on #git asked about existing documented
workflows, and there is very little. It would be interesting project for
someone to build a 'Garden of Git Workflows' (or a Labyrinth) - for each
workflow, detailed self-contained documentation ranging from lone developer
with topic branches over repo.or.cz/github forks workflow, the workflows
of "leaf contributors", lieutenants and main integrators of the mail-oriented
kernel/git workflow, up to the single-central-repository workflows.
There are bits here and there, but the main problem is that they are not
self-contained. It might be nice to have something like a set of military
manuals, appropriate for the roles of the particular developers.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Contributors, please check your names
From: Jakub Narebski @ 2008-07-17 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8ww0j4ye.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> There is a "mailmap" mechanism to consolidate them; it allows us to
> specify what human-readable name should be used for given e-mail address.
> The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
> from me, <author@example.xz>, are marked without abbreviating periods in
> my name", and we can add this entry to the toplevel .mailmap file to fix
> it:
>
> A. U. Thor <author@example.xz>
>
> It tells the shortlog (and --pretty=format:%aN in recent enough git)
> mechanism to give huma readable name "A. U. Thor" anytime it sees
> <author@example.xz> e-mail address, regardless of what the Author:
> header in the commit object says.
What about if some authors use different _email_ address, instead?
Is there any way for shortlog to consider them the same?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-17 14:38 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170508j3d3c1ef8j49df576fc47debe2@mail.gmail.com>
On Thu, Jul 17, 2008 at 01:08:19PM +0100, Nigel Magnay wrote:
> When doing a git submodule update, it fetches any missing submodule
> commits from the repository specified in .gitmodules. If you instead
> want to pull from another repository, you currently need to do a fetch
> in each submodule by hand.
>
> Signed-off-by: Nigel Magnay <nigel.magnay@gmail.com>
I don't think it is good idea to hijack git submodule update for this.
This command has a specific purpose:
"When I pulled new version of the main tree, bring my
submodule checkouts in line with whatever is specified
within the new tree revision."
Your usage scenario has nothing to do with that, it is about "batch
manipulation" of all the submodules at once in a certain way. I think
using the same command for two conceptually pretty much unrelated
purposes will only clutter up the UI, and we should think of a better
general interface pattern for these operations.
In the new git-submodule description, it is said that
"This command will manage the tree entries and contents of the
gitmodules file for you."
and I think we should keep it at this; anything that is related to
submodules, but does not do this directly, would IMHO live better
as some kind of "submodule-recursive" extension of other existing
commands. Say, would this particular need of yours be served by a
hypothetical command like
git checkout --submodules nifty
to check out branch nifty of all submodules or am I misunderstanding
what are you trying to achieve?
If not, then actually even _much_ more elegant solution for this
particular problem would be to store submodule.*.branch in .gitmodules
appropriate to the -b parameter of git submodule add. Then, in branch
'nifty' of the main project, you would set submodule.*.branch to 'nifty'
too. Then, in order to bring all the submodules to the latest version,
I could imagine something like
git pull --submodules
(and possibly just abort at the first sight of a conflict, for
starters).
Let's figure up some UI that is nifty and clean. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-17 14:26 UTC (permalink / raw)
To: Peter Valdemar Mørch; +Cc: git
In-Reply-To: <487F4A9A.1090108@morch.com>
On Thu, Jul 17, 2008 at 03:35:22PM +0200, Peter Valdemar Mørch wrote:
> E.g. something I seem to succeed with sometimes, but not consistently is
> the equivalent of "svn revert -R .". "git help reset"? Yup: "git reset
> --hard HEAD ." When I run into merge conflicts, I'll probably look at
> such a doc again, but other than that I'll probably use man pages most.
You find quick alias to be a useful replacement for "svn revert -R
<file>" (aka "hg revert <file>" and "bg revert <file>"):
git config --global alias.revert-file "checkout HEAD --"
Once you run this command, you can now do "git revert-file <file>"
which I personally find very handy. Sometimes I only want to revert
one file, and not all of the files in the working directory, which is
what "git reset --hard" will do.
(Note that "git revert" does something else useful, but which is not
the same as "hg revert", "bk revert" and "svn revert". Oh well, nobody
ever said DSCM's had to be consistent.)
- Ted
^ permalink raw reply
* RE: Considering teaching plumbing to users harmful
From: Craig L. Ching @ 2008-07-17 14:21 UTC (permalink / raw)
To: Johannes Schindelin, Avery Pennarun; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807170024310.4318@eeepc-johanness>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Johannes Schindelin
> Sent: Wednesday, July 16, 2008 5:28 PM
> To: Avery Pennarun
> Cc: Junio C Hamano; git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> So can those people who have something to say about _my_
> subject of discussion please speak up? I think this issue
> has not been discussed properly.
>
I've read this whole thread with great interest as I started learning
and using git a few months ago. While I agree with you to a degree,
there is a class of "newbies" to git who need more than just the basics
that you outlined. For instance, I'm in the process of evaluating
VCS's, and DVCS's in particular, to replace CVS at our workplace.
Because of that, I need to get "up to speed" as fast as I can. I need
to know about branches, how to browse history, merging, conflicts, etc.
It is true, though, that I have a lot of experience doing these things
already by virtue of the fact that I've used VCS's for over a decade and
have been evaluating DVCS's for at least the past 3 years, so I have a
bit of a head start on these things. To learn about these things,
though, the sheer size of Git's vocabulary is huge compared to other
DVCS's. That's a *good* thing, but it also makes it a bit harder to
learn it all. It's just a fact of life.
The first DVCS I learned was monotone. And I think what helped me the
most in learning it is that it's syntax is very simple (you'd probably
say limited compared to git, but that's neither here nor there, if you
stick to your original list, git is as simple as monotone), it's
repository format, the fact that each developer could keep one
repository and create workspaces off of it was perfect for our
workflows. What I think really helped with learning monotone is that
they had a bunch of common workflows already documented and we could
simply try them out. Maybe if Git had a few different workflows
documented that might help. I know we have a "Git for SVN Users"
workflow, but if you want to move beyond that, it might be good to have
some of the more complex workflows documented. I think some people have
hinted at that suggestion but that maybe it just hasn't been explicitly
said.
> Thanks.
> Dscho
> --
Cheers,
Craig
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Johannes Schindelin @ 2008-07-17 14:16 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170703l57fe26d2h1e9c4db1c38dd6f1@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
> Your attitude seems to be that the status-quo is in some way desirable;
> "It's no wonder that this tool is awkward to use in your workflow.".
> This workflow is really common, and there's actual, real people on this
> list complaining about it. Don't we think it could be improved to be
> non-awkward ?
I do not think that the status quo is the best possible.
But I think that the way you go makes things so confusing that those who
use it apart from you will have problems.
For example, in your setup everybody would have to install _different_
remotes in every submodule.
And then some would ask themselves why the original origin was not good
enough.
And others would specify "-o origin" all the time, thinking it was
required.
There must be a better way to promote submodules to a usable state,
Dscho
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Gerrit Pape @ 2008-07-17 14:08 UTC (permalink / raw)
To: git, Eric Wong
In-Reply-To: <20080706192850.32547.qmail@4480698c45f1ed.315fe32.mid.smarden.org>
On Sun, Jul 06, 2008 at 07:28:50PM +0000, Gerrit Pape wrote:
> With subversion 1.5.0 (C and perl libraries) the git-svn selftest
> t9101-git-svn-props.sh fails at test 25 and 26. The following commands
> The breakage was reported by Lucas Nussbaum through
> http://bugs.debian.org/489108
> ---
> git-svn.perl | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> I ran into this on Debian/unstable. With svn 1.5.0 the selftest fails
> without the patch, with svn 1.4.6 it succeeds with and without the
> patch. I'm not familar with the svn interfaces, not sure whether this
> is a regression in subversion, or a bug in git-svn.
Hi, while this commit fixed the selftests, it unfortunately is a
regression
http://thread.gmane.org/gmane.comp.version-control.git/87822/
http://bugs.debian.org/490400
I'm still not sure whether this is a git-svn problem, or actually a
problem in subversion 1.5.0
$ perl -MSVN::Client -e \
'sub print_names { print "<$_[0]>\n"; } $ctx=new SVN::Client;
$ctx->status(".", "BASE", \&print_names, 1, 1, 0, 1);' | head -5
perl:
/build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_subr/path.c:119: svn_path_join: Assertion `is_canonical(base, blen)' failed.
$
[0]
Regards, Gerrit.
[0] http://bugs.debian.org/359679
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 14:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807171351380.8986@racer>
On Thu, Jul 17, 2008 at 1:58 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Thu, 17 Jul 2008, Nigel Magnay wrote:
>> >
>> >> When doing a git submodule update, it fetches any missing submodule
>> >> commits from the repository specified in .gitmodules.
>> >
>> > Huh? It takes what is in .git/config! Not what is in .gitmodules.
>>
>> Huh? And where does .git/config get it from? Oh, that's right,
>> .gitmodules.
>
> Oh, that's right, after "git submodule init". Right before you are
> supposed to change them if your setup commands that.
>
>> > So if you have another remote (or URL, e.g. if you have ssh:// access,
>> > but the .gitmodules file lists git://), just edit .git/config.
>>
>> So for my usecase, you'd have me go in and change *evey single one* of
>> my submodule refs from the centralised repository, *every time* I want
>> to do a peer review?
>
> No.
>
>> Doesn't the current system strike you as being somewhat centralised in
>> nature?
>
> No.
>
>> > I meant, that is the whole _point_ of having a two-step init/update
>> > procedure.
>>
>> Are you just determined that submodules should remain useless for "the
>> rest of us"?
>
> No.
>
> If you really need to change the "origin" back and forth between reviews,
> while the committed state of the superproject stays the same, then
> something is seriously awkward and needs to be streamlined in your setup.
>
> Because when the superproject's revision stays the same, "git submodule
> update" may fetch additional objects if you specify another remote, but it
> will check out just the same revisions of the submodules. Because they
> were committed as such.
>
> But if you want to get objects from another server (as opposed to update
> the submodules' working directories to the latest committed revisions),
> which happens to have the identical layout of the principal server (which
> I would deem another setup peculiarity to be fixed), you might want to
> look into the recurse patch that was flying about on this list a few
> months back.
The layout wouldn't be the same - the submodules would be in the
corresponding subdirectories (I guess it could have some other,
stranger layout, but I'd consider that peculiar). So you're right, the
layout is different, which makes editing the config all the more
tedious.
I don't want to change the *origin* back and forth. I want to be able
to use repos with submodules in them as easily and as transparently
and in the same distributed way as git allows me to do if they don't
contain submodules. I.E I don't want it to be such a sisyphean
challenge every time with umpteen scripts to complete a usecase that
really ought to be supported as standard. The very first thing that
I've hit is that submodule update only talks to origin, so 'git pull
fred && git submodule update' falls flat on its face. Why am I being
forced to update config just to have a look-see at fred's project?
Your attitude seems to be that the status-quo is in some way
desirable; "It's no wonder that this tool is awkward to use in your
workflow.". This workflow is really common, and there's actual, real
people on this list complaining about it. Don't we think it could be
improved to be non-awkward ?
In the ideal UI, it ought to be possible to make the use of projects
with submodules (almost) completely transparent, like it is in the
vcs-that-dare-not-speak-it's-name.
^ permalink raw reply
* [PATCH] Add a few names to the mailmap
From: Johannes Schindelin @ 2008-07-17 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8ww0j4ye.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1936 bytes --]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I hope that my mailer does not break UTF-8 encoded names...
.mailmap | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/.mailmap b/.mailmap
index f88ae77..ca2e17e 100644
--- a/.mailmap
+++ b/.mailmap
@@ -5,22 +5,28 @@
# same person appearing not to be so.
#
+Alexander N. Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
Chris Shoemaker <c.shoemaker@cox.net>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
+David D. Kilzer <ddkilzer@kilzer.net>
David Kågedal <davidk@lysator.liu.se>
+David S. Miller <davem@davemloft.net>
+Dirk Süsserott <newsletter@dirk.my1.cc>
Fredrik Kuivinen <freku045@student.liu.se>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
+İsmail Dönmez <ismail@pardus.org.tr>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
+Jonathan Nieder <jrnieder@uchicago.edu>
Junio C Hamano <junio@twinsun.com>
Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
@@ -30,9 +36,11 @@ Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Michael Coleman <tutufan@gmail.com>
+Michael W. Olson <mwolson@gnu.org>
Michele Ballabio <barra_cuda@katamail.com>
Nanako Shiraishi <nanako3@bluebottle.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+Philippe Bruhat (BooK) <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
--
1.5.6.3.626.gf5cf.dirty
^ permalink raw reply related
* Re: Considering teaching plumbing to users harmful
From: Peter Valdemar Mørch @ 2008-07-17 13:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <20080717125536.GO2167@mit.edu>
Theodore Tso tytso-at-mit.edu |Lists| wrote:
> The top-level man page has a listing of what is porcelain and what is
> plumbing --- although there is some disagreement.
Cool! I missed that! Thanks.
> Have you taken a look at the intro-level materials such as "Everyday
> Git in 20 commands or so"[1], the git tutorial[2], the official "Git's
> User Manual"[3], or the "Git-SVN crash course"[4]?
Yup. I started there and am happily coding, committing, branching &
merging away. Now man pages are closest to my fingers in the terminal. :-)
E.g. something I seem to succeed with sometimes, but not consistently is
the equivalent of "svn revert -R .". "git help reset"? Yup: "git reset
--hard HEAD ." When I run into merge conflicts, I'll probably look at
such a doc again, but other than that I'll probably use man pages most.
Just wanted to offer the newbie's opinion, that it would be helpful for
me with "Here be plumbing. Newbies look elsewhere" notices when I'm on
my way down the wrong track.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* [PATCH 2/2 v2] git-gui: "Stage Line": Treat independent changes in adjacent lines better
From: Johannes Sixt @ 2008-07-17 13:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Johannes Sixt
In-Reply-To: <20080716003503.GA24339@spearce.org>
Assume that we want to commit these states:
Old state == HEAD Intermediate state New state
--------------------------------------------------------
context before context before context before
old 1 new 1 new 1
old 2 old 2 new 2
context after context after context after
that is, want to commit two changes in this order:
1. transform "old 1" into "new 1"
2. transform "old 2" into "new 2"
[This discussion and this patch is about this very case and one other case
as outlined below; any other intermediate states that one could imagine are
not affected by this patch.]
Now assume further, that we have not staged and commited anything, but we
have already changed the working file to the new state. Then we will see
this hunk in the "Unstaged Changes":
@@ -1,4 +1,4 @@
context before
-old 1
-old 2
+new 1
+new 2
context after
The obvious way to stage the intermediate state is to apply "Stage This
Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this
intermediate state:
context before
old 2
new 1
context after
which is not what we wanted. In fact, it was impossible to stage the
intermediate state using "Stage Line". The crux was that if a "+" line was
staged, then the "-" lines were converted to context lines and arranged
*before* the "+" line in the forged hunk that we fed to 'git apply'.
With this patch we now treat "+" lines that are staged differently. In
particular, the "-" lines before the "+" block are moved *after* the
staged "+" line. Now it is possible to get the correct intermediate state
by staging "-old 1" and "+new 1". Problem solved.
But there is a catch.
Noticing that we didn't get the right intermediate state by staging
"-old 1" and "+new 1", we could have had the idea to stage the complete
hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same.
The reason is that there is the exact symmetric problem with unstaging the
last "-" and "+" line that are in adjacent blocks of "-" and "+" lines.
This patch does *not* change the way in which "-" lines are *unstaged*.
Why? Because if we did (i.e. move "+" lines before the "-" line after
converting them to context lines), then it would be impossible to stage
this intermediate state:
context before
old 1
new 2
context after
that is, it would be impossible to stage the two independet changes in the
opposite order.
Let's look at this case a bit further: The obvious way to get this
intermediate state would be to apply "Stage This Line" to "-old 2" and
"+new 2". Before this patch, this worked as expected. With this patch, it
does not work as expected, but it can still be achieved by first staging
the entire hunk, then *unstaging* "-old 1" and "+new 1".
In summary, this patch makes a common case possible, at the expense that
a less common case is made more complicated for the user.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
The patch is unmodified, but I hope the commit message is clearer.
-- Hannes
lib/diff.tcl | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index ee7f391..77990c5 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -411,6 +411,53 @@ proc apply_line {x y} {
set hh [lindex [split $hh ,] 0]
set hln [lindex [split $hh -] 1]
+ # There is a special situation to take care of. Consider this hunk:
+ #
+ # @@ -10,4 +10,4 @@
+ # context before
+ # -old 1
+ # -old 2
+ # +new 1
+ # +new 2
+ # context after
+ #
+ # We used to keep the context lines in the order they appear in the
+ # hunk. But then it is not possible to correctly stage only
+ # "-old 1" and "+new 1" - it would result in this staged text:
+ #
+ # context before
+ # old 2
+ # new 1
+ # context after
+ #
+ # (By symmetry it is not possible to *un*stage "old 2" and "new 2".)
+ #
+ # We resolve the problem by introducing an asymmetry, namely, when
+ # a "+" line is *staged*, it is moved in front of the context lines
+ # that are generated from the "-" lines that are immediately before
+ # the "+" block. That is, we construct this patch:
+ #
+ # @@ -10,4 +10,5 @@
+ # context before
+ # +new 1
+ # old 1
+ # old 2
+ # context after
+ #
+ # But we do *not* treat "-" lines that are *un*staged in a special
+ # way.
+ #
+ # With this asymmetry it is possible to stage the change
+ # "old 1" -> "new 1" directly, and to stage the change
+ # "old 2" -> "new 2" by first staging the entire hunk and
+ # then unstaging the change "old 1" -> "new 1".
+
+ # This is non-empty if and only if we are _staging_ changes;
+ # then it accumulates the consecutive "-" lines (after converting
+ # them to context lines) in order to be moved after the "+" change
+ # line.
+ set pre_context {}
+
set n 0
set i_l [$ui_diff index "$i_l + 1 lines"]
set patch {}
@@ -422,19 +469,27 @@ proc apply_line {x y} {
[$ui_diff compare $the_l < $next_l]} {
# the line to stage/unstage
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
if {$c1 eq {-}} {
set n [expr $n+1]
+ set patch "$patch$pre_context$ln"
+ } else {
+ set patch "$patch$ln$pre_context"
}
+ set pre_context {}
} elseif {$c1 ne {-} && $c1 ne {+}} {
# context line
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
+ set patch "$patch$pre_context$ln"
set n [expr $n+1]
+ set pre_context {}
} elseif {$c1 eq $to_context} {
# turn change line into context line
set ln [$ui_diff get "$i_l + 1 chars" $next_l]
- set patch "$patch $ln"
+ if {$c1 eq {-}} {
+ set pre_context "$pre_context $ln"
+ } else {
+ set patch "$patch $ln"
+ }
set n [expr $n+1]
}
set i_l $next_l
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* Re: [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Heikki Orsila @ 2008-07-17 13:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080717122911.32334.73465.stgit@localhost>
On Thu, Jul 17, 2008 at 02:29:20PM +0200, Petr Baudis wrote:
> +Submodules allow foreign repositories to be embedded within a dedicated
> +subdirectory of the source tree, always pointed at a particular commit.
> +They are not to be confused with remotes, which are meant mainly for branches
> +of the same project; submodules are meant for different projects you would like
> +to make part of your source tree, while the history of the two projects still
> +stays completely independent and you cannot modify the contents of the
> +submodule from within the main project.
That is nice, thanks!
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Stephan Beyer @ 2008-07-17 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk01hqzz.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> * sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
> . Migrate git-am to use git-sequencer
> . Add git-sequencer test suite (t3350)
> . Add git-sequencer prototype documentation
> . Add git-sequencer shell prototype
>
> I haven't looked at the updated series yet. I should, but nobody else
> seems to be looking at these patches, which is somewhat depressing but
> understandable. Summer is slower ;-)
imho there is no need to hurry, but if I can help, just tell me how.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 5/7] git mv: Support moving submodules
From: Petr Baudis @ 2008-07-17 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcapme0q.fsf@gitster.siamese.dyndns.org>
Hi!
On Wed, Jul 16, 2008 at 07:37:57PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... The horrid
> > index_path_src_sha1 hack is unfortunately much worse,
>
> This one certainly is ugly beyond words.
;-)
> By the way, why is it even necessary to rehash the contents when you run
> "mv"?
>
> IOW,
>
> $ >foo
> $ git add foo
> $ echo 1 >foo
> $ git mv foo bar
>
> makes "foo" disappear from the index and adds "bar", but it makes the
> local change added to the index at the same time.
>
> Side note. It actually is a lot worse than that. When you move
> something to another existing entry, the code does not even add
> the object name of moved entry recorded in the index, nor rehashes
> the moved file. This is totally inconsistent!
>
> I personally think these buggy behaviours you are trying to inherit are
> making this patch more complex than necessary. Perhaps this needs to be
> fixed up even further (you did some fix with the first patch) before
> adding new features? For example, I think it is a bug that the
> "overwrite" codepath does not work with symlinks.
I agree that it would be much cleaner to fix this; I got puzzled about
this behaviour a bit, but I was afraid to break the traditional
behaviour. However, if you are feeling this brave, patch to follow up
shortly. :-)
> * Then, only for case (1), you do not call add_file_to_cache() -- because
> you know you do not have anything you can rehash; instead, factor out
> the codepath "git-update-index --cacheinfo" uses and call that.
This is excellent hint, sort of what I hoped for, thanks! I forgot
about --cacheinfo completely, which is truly a shame especially when I
look at the history of this switch. ;-) (BTW, curiously, the commit
lists Linus as an author even though the patch is yours. Maybe this was
merely some imperfection of the early scripts around Git, though.)
I really did not touch git internals for way too long.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Sequencer migration patches
From: Stephan Beyer @ 2008-07-17 13:05 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Christian Couder, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <cover.1216233918.git.s-beyer@gmx.net>
Hi,
Stephan Beyer wrote:
> Rebasing 100 commits takes 10.1 seconds instead of only 4.8 seconds
> on my test machine.
Btw, the builtin-sequencer needs 1.7 seconds to pick that 100 commits
on my test machine.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 6/7] git rm: Support for removing submodules
From: Johannes Schindelin @ 2008-07-17 12:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717123501.GD10151@machine.or.cz>
Hi,
On Thu, 17 Jul 2008, Petr Baudis wrote:
> On Thu, Jul 17, 2008 at 12:41:57AM +0200, Johannes Schindelin wrote:
> > On Wed, 16 Jul 2008, Petr Baudis wrote:
> >
> > > This patch adds support for removing submodules to 'git rm',
> > > including removing the appropriate sections from the .gitmodules
> > > file to reflect this
> >
> > I have no time to look at the whole series, or even at the patch, but
> > I have concerns. Do you really remove the whole directory? Because
> > if you do, you remove more than what can be possibly reconstructed
> > from the object store.
>
> no; I remove only the index entry and the empty directory made for
> non-checked-out submodules (I just try rmdir() and ignore ENOTEMPTY
> error). I make that clear in git rm documentation, but not in the patch
> description; I will fix that.
Thanks for explanation!
> > I wonder if it really makes sense to integrate that into git-rm, and
> > not git-submodule, if only to introduce another level of consideration
> > for the user before committing what is potentially a big mistake.
>
> That is good question and I forgot to elaborate on this in the cover
> letter. However, I believe that integrating this functionality into the
> basic commands makes for a smoother user experience, following the
> principle of the least surprise.
Makes sense,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Johannes Schindelin @ 2008-07-17 12:58 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170521s26693381m60648468cce1c41c@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
> On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 17 Jul 2008, Nigel Magnay wrote:
> >
> >> When doing a git submodule update, it fetches any missing submodule
> >> commits from the repository specified in .gitmodules.
> >
> > Huh? It takes what is in .git/config! Not what is in .gitmodules.
>
> Huh? And where does .git/config get it from? Oh, that's right,
> .gitmodules.
Oh, that's right, after "git submodule init". Right before you are
supposed to change them if your setup commands that.
> > So if you have another remote (or URL, e.g. if you have ssh:// access,
> > but the .gitmodules file lists git://), just edit .git/config.
>
> So for my usecase, you'd have me go in and change *evey single one* of
> my submodule refs from the centralised repository, *every time* I want
> to do a peer review?
No.
> Doesn't the current system strike you as being somewhat centralised in
> nature?
No.
> > I meant, that is the whole _point_ of having a two-step init/update
> > procedure.
>
> Are you just determined that submodules should remain useless for "the
> rest of us"?
No.
If you really need to change the "origin" back and forth between reviews,
while the committed state of the superproject stays the same, then
something is seriously awkward and needs to be streamlined in your setup.
Because when the superproject's revision stays the same, "git submodule
update" may fetch additional objects if you specify another remote, but it
will check out just the same revisions of the submodules. Because they
were committed as such.
But if you want to get objects from another server (as opposed to update
the submodules' working directories to the latest committed revisions),
which happens to have the identical layout of the principal server (which
I would deem another setup peculiarity to be fixed), you might want to
look into the recurse patch that was flying about on this list a few
months back.
Hth,
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-17 12:55 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <487EF519.5070902@sneakemail.com>
On Thu, Jul 17, 2008 at 09:30:33AM +0200, "Peter Valdemar Mørch (Lists)" wrote:
>
> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even
> sticking to porcelain, it is a feature-rich new tool I have in my hands!
>
> I'm missing clarity about what is porcelain and what is plumbing. `git
> help` shows
The top-level man page has a listing of what is porcelain and what is
plumbing --- although there is some disagreement. Johannes was
complaining about people using git rev-parse in tutorials and saying
that there was no way that was porcelain, but in fact it is *not*
listed as plumbing in the git man page. So I don't think there is
really a strong black-and-white category, but rather a certain set of
shades of gray, as it were.
> Is this list exactly the list of porcelain commands? Then say so there.
> Neither `git help diff` nor `git help ls-tree` say whether they are
> porcelain or plumbing commands. `git help diff` mentions git-diff-index,
> which i suspect is plumbing. When I read a man page, it would be nice to
> know whether a command (either the topic of the page or another
> mentioned command) is intended as porcelain or not.
My personal long-standing complaint is that there are certain man
pages like "git log" where in order to see all of the options which it
can take, the man page for git-log redirects you to a man page for
plumbing. Great way to scare the users. :-)
Have you taken a look at the intro-level materials such as "Everyday
Git in 20 commands or so"[1], the git tutorial[2], the official "Git's
User Manual"[3], or the "Git-SVN crash course"[4]? Those are probably
the best place to begin --- and to basically treat the git man pages
as reference materials with a huge number of controls that you won't
use or need to use for a long time --- if ever. It's like the 10,000
features hidden inside Microsoft Office. The features are all
indispensable to *someone*, but everyone has a different set of the
100 features which they all *have* to have. (And of course, the 20 or
so features that everyone really uses. :-)
> All of this of course assumes that there is consensus and a clear
> distinction between what is porcelain and what is plumbing which I'm
> don't even know if there is.
I don't think so. It's like what the judge said about pornography ---
I know it when I see it. :-)
And note that there's nothing *wrong* with using plumbing commands.
It's just that from a pedagogical point of view, they might not
necessarily be the best place to start.
- Ted
[1] http://www.kernel.org/pub/software/scm/git/docs/everyday.html
[2] http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
[3] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
[4] http://git.or.cz/course/svn.html
^ permalink raw reply
* Re: [PATCH] cvsserver: Add support for packed refs
From: Lars Noschinski @ 2008-07-17 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, fabian.emmes
In-Reply-To: <alpine.LSU.1.00.0807171346560.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hello!
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-17 14:31]:
>On Thu, 17 Jul 2008, Lars Noschinski wrote:
>
>> req_update still parses /refs/heads manually. Replace this by
>> a call to show-ref.
>>
>> Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
>> ---
>> git-cvsserver.perl | 25 +++++++++----------------
>> 1 files changed, 9 insertions(+), 16 deletions(-)
>>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index b00d1c2..0e4f5f9 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -947,24 +947,17 @@ sub req_update
>> # projects (heads in this case) to checkout.
>> #
>> if ($state->{module} eq '') {
>> - my $heads_dir = $state->{CVSROOT} . '/refs/heads';
>> - if (!opendir HEADS, $heads_dir) {
>> - print "E [server aborted]: Failed to open directory, "
>> - . "$heads_dir: $!\nerror\n";
>> - return 0;
>> - }
>> - print "E cvs update: Updating .\n";
>> - while (my $head = readdir(HEADS)) {
>> - if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
>> - print "E cvs update: New directory `$head'\n";
>> - }
>> - }
>> - closedir HEADS;
>> - print "ok\n";
>> - return 1;
>> + my $showref = `git show-ref --heads`;
>> + for my $line (split '\n', $showref) {
>> + if ( $line =~ m% refs/heads/(.*)$% ) {
>> + print "M $1\t$1\n";
>
>In the removed part, I see that this changes behaviour from "E cvs update:
>..." to "M ...".
Good catch, this part is indeed somewhat busted. The tested clients did
not care, but this should be changed nevertheless to be the same as the
old behaviour.
>I do not know the CVS protocol well enough to know if that is still
>correct.
>
>BTW from the removed part, it seems that the indentation was done with
>tabs formerly, and with spaces now; please use tabs instead.
Actually, the old indetation was wrong. The biggest part of the file
(and the surrounding code) is indented by spaces.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Dmitry Potapov @ 2008-07-17 12:38 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <487EF519.5070902@sneakemail.com>
On Thu, Jul 17, 2008 at 11:30 AM, "Peter Valdemar Mørch (Lists)"
<4ux6as402@sneakemail.com> wrote:
>
> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even
> sticking to porcelain, it is a feature-rich new tool I have in my hands!
>
> I'm missing clarity about what is porcelain and what is plumbing. `git help`
> shows
>
> "The most commonly used git commands are:" add .. tag.
>
> Is this list exactly the list of porcelain commands? Then say so there.
There are a few other commands that are considered as porcelain, but they
are not so often used or used for very specific purposes, such sending
patches by email. So, you do not have to bother about them right now.
In fact, even this list may be too long to be learned at once. It is
better to proceed step-wise, like this:
=== Getting started ===
1. Creating your repo
git init
git clone
2. Commiting your changes
git add
git commit
There are also git mv, git rm for those who need them.
3. Inspect your changes before committing them
git status
git diff
4. Inspecting history
git log
5. Synchronization with the upstream
git pull
git push
=== More commands ===
6. How to revert my changes?
6.1. reverting uncommitted changes
git checkout file
git checkout HEAD file
6.2. committed but not publish changes
git reset HEAD^
git reset --hard HEAD^
6.3. published changes
git revert
7. Who introduced this change?
git log -S as better alternative to git blame
8. Some useful "tricks"
git grep
git add -p
git diff --cached
git commit --amend
git show
git log -p
=== Working with branches ===
9. Creating branches and tags
git tag
git branch
git checkout
10. Merging is easy
git merge
By the way:
git pull = git fetch + git merge FETCH_HEAD
git merge branch = git pull . branch
11. What is rebase?
When can it be useful?
Advantages and disadvantages.
=== More "advanced" commands ===
12. git safety net
git log -g
13. Find the change that introduced a bug
git bisect
14. Short review other commands:
git gc
git archive
git-cherry-pick
git remote
git format-patch
git apply
git am
===
> Neither `git help diff` nor `git help ls-tree` say whether they are
> porcelain or plumbing commands. `git help diff` mentions git-diff-index,
> which i suspect is plumbing. When I read a man page, it would be nice to
> know whether a command (either the topic of the page or another mentioned
> command) is intended as porcelain or not.
I agree, it is very confusing for beginners. The rule of the thumb that
helped me when I started was that commands with dash in their names are
plumbing (there are a few exceptions though).
Dmitry
^ permalink raw reply
* Re: [PATCH 6/7] git rm: Support for removing submodules
From: Petr Baudis @ 2008-07-17 12:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807170038430.4318@eeepc-johanness>
Hi,
On Thu, Jul 17, 2008 at 12:41:57AM +0200, Johannes Schindelin wrote:
> On Wed, 16 Jul 2008, Petr Baudis wrote:
>
> > This patch adds support for removing submodules to 'git rm', including
> > removing the appropriate sections from the .gitmodules file to reflect
> > this
>
> I have no time to look at the whole series, or even at the patch, but I
> have concerns. Do you really remove the whole directory? Because if you
> do, you remove more than what can be possibly reconstructed from the
> object store.
no; I remove only the index entry and the empty directory made for
non-checked-out submodules (I just try rmdir() and ignore ENOTEMPTY
error). I make that clear in git rm documentation, but not in the patch
description; I will fix that.
> I wonder if it really makes sense to integrate that into git-rm, and not
> git-submodule, if only to introduce another level of consideration for the
> user before committing what is potentially a big mistake.
That is good question and I forgot to elaborate on this in the cover
letter. However, I believe that integrating this functionality into the
basic commands makes for a smoother user experience, following the
principle of the least surprise. It is difficult for me to argue
extensively in further favor of this choice, though. :-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ 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