* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-20 6:24 UTC (permalink / raw)
To: Ari Entlich; +Cc: Michael Witten, git
In-Reply-To: <1192859748.13347.146.camel@g4mdd.entnet>
On Sat, Oct 20, 2007 at 01:55:48AM -0400, Ari Entlich wrote:
> Well, I also want to move the working directory file so that the index
> and the working directory still match up and so that their differences
> are preserved. Therefore, --cached isn't quite right (see Shawn's
> messages and my response to them).
Ah, OK. I understand now. So what you would want could be accomplished
with something like:
mv A B
(git-ls-files -s | sed s/A$/B/;
echo 0 0000000000000000000000000000000000000000 A) \
| git-update-index --index-info
IOW:
1. move working tree A to B
2. create staged entry B, same as staged entry A
3. remove staged entry A
> Hmm, that's an interesting point. Are you talking about situations in
> which your changes after (1) leave the program in an uncompilable state?
No, I meant more that the state you have staged will never have actually
existed in your working tree, so you could not possibly have tested it.
However, it may be that the changes you are trying to avoid staging are
trivial, and you're willing to accept that. And git shouldn't stand in
your way.
And it sounds like you don't necessarily want to make a _commit_ out of
this, you just want to keep working and not have git-mv munge your
staged state.
> I don't really see why you're analyzing the situations in which this
> would be used. I think it should be obvious from my descriptions of my
Because I was having trouble understanding what Michael was trying to
accomplish with his "here are two methods, and one is better" since they
seemed to do different things. But that is perhaps my fault for joining
the thread in the middle. I may have simply caused more confusion by
getting involved. :)
Now I think I understand exactly what you're trying to accomplish,
and I agree that it makes sense. Shawn is right that "git-mv --cached"
doesn't do what you want, since to be consistent with other tools it
wouldn't touch the working tree (though I wonder if you would be
satisfied with "git-mv --cached A B; mv A B"). I think at this point the
best way forward is to produce a patch and try to solicit comments (in
particular, which behaviors should be supported (current, --cached, or
what you are proposing) and which should be the default).
> But... that's not even the point I was going to make. I think the
> questions you should be asking are things like "Does this fit with the
> overall architecture?", "Does this or doesn't this provide power and
> flexibility to the user?", etc. Is git being made for "the 80%" that use
There seems to be a strong sentiment among the various gits that you
shouldn't build in flexibility for the sake of flexibility if there's no
good use for it. I tend to be less of that sentiment than some others
here, but I think when proposing a feature it is still worth saying "and
here's why it's useful."
> Sorry if anything I've said here sounded confrontational; that was not
> not my intent at all. I'm just raising some points I think are
> important. I don't want any flame wars...
I think you stated your position fine. And we've had enough flame wars
around here lately to last us a while.
-Peff
^ permalink raw reply
* [BUG] git-mv submodule failure
From: Yin Ping @ 2007-10-20 6:01 UTC (permalink / raw)
To: git
project
.git
file1
submoudle
.git
file2
$ cd project
$ git-mv submodule submodule1
fatal: source directory is empty, source=submodule, destination=submodule1
However, the following is ok and rename is automatically detected
$ cd project
$ mv submodule submodule1
$ git-add submodule1
$ git-commit -a
which gives in vim:
# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: submodule -> submodule1
#
--
franky
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Ari Entlich @ 2007-10-20 5:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071019015419.GV14735@spearce.org>
On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:
> Line wrapping email at under 80 columns would be nice. It makes it
> easier to read the message, and more importantly, easier to quote
> a few times during discussion.
Yeah, sorry about that. As I said, the crappy webmail client I was using
was screwing up. I'm using a real email client now.
> I'm somewhat hesistant to change existing behavior, as users may
> be used to it or relying upon it within their scripts. But you
> make an excellent argument about why the current git-mv behavior
> is perhaps less than ideal.
See my response to Wincent's message for what I said about this.
One minor issue (since you talk about programming stuff below) is that,
from my cursory survey of builtin-mv.c, a slight restructuring might be
required for this to work and for the solution to satisfy my coding
standards. This would be because you'd need to change the names of
individual cache entries as opposed to removing one and adding one. This
is a minor issue though, I'm sure I can figure out how to get it to work
somehow.
> Elsewhere in git we use the --cached command line option to mean
> "only make the change in the index". For example the git-apply
> --cached option. You could start a patch that uses --cached to
> trigger the new behavior you propose and see if people are interested
> in changing the default once the feature is working and available
> for experimentation.
>From a later email...
> But I was originally *way* wrong to propose --cached for this usage
> in git-mv. --cached means "apply *ONLY* to the index" and "do *NOT*
> touch the working tree". Here we want to touch the working tree
> in the sense of moving the file. So --cached is not the correct
> option name.
Hmm yeah, that did occur to me after I read your original message...
> --index is used in Git for places were we update *both* the index
> and the working directory (git-apply --index). So actually I should
> have suggested "git-mv --index". Whoops.
Alright then, I don't know about that particular convention. If this
behavior can't be made default, git mv --index should activate it? I
there anything else that might be more descriptive?
> > I'm willing to look into what changes would need to be made to the
> > code for this change to happen; I'm not asking for someone to do
> > all the work for me. :)
> >
> > So... Yeah. I'd like to know what people think about this before
> > I put a significant amount of effort into it. After all, we know
> > how lazy programmers are... :)
>
> See builtin-mv.c around l.264-283. This is where we are removing
> the old names from the index (in memory) and inserting the new
> names. Instead of calling add_file_to_cache() you would want
> to use something like add_cacheinfo() in builtin-update-index.c,
> specifying the old sha1, ce_flags and ce_mode.
Might it be possible to simply get the struct cache_entry for the file
which we want to rename, change its name property (would this involve
xreallocing it?), and change the ce_namelen field of ce_flags?
In any case, I think the ce_flags would need to be changed to reflect
the new name length. Also, it seems that the old ce_mtime, ce_dev,
ce_ino, ce_uid, ce_gid, and ce_size could be used too... ce_ctime would
need to be updated...
> I'm sure Junio could probably give you a better starting point
> than I can, as he's more familiar with this sort of code, but that
> should still get you looking in the right direction and maybe get
> a working implementation together that you can share for discussion.
Yeah, I'd appreciate any help I can get. The people on #git were
invoking the "the code is the documentation" ideology. :)
So... Ping Junio...? I actually haven't seen any messages from him since
I subscribed to this list (I've only gotten about 300 messages so far,
but I'd expect to see a lot from him as he's the maintainer...). Is he
away at the moment or something?
Thanks,
Ari
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Ari Entlich @ 2007-10-20 5:55 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Michael Witten, Jeff King, git
On Fri, 2007-10-19 at 13:33 +0200, Wincent Colaiuta wrote:
> El 19/10/2007, a las 4:29, Michael Witten escribió:
> > Ah. Basically my 'pseudo-code' is correct, but redundant.
>
> If I understood the original poster's proposal then I don't think your
> code does what he asked for:
>
> > What you want to happen is the following:
> >
> > git show HEAD:A.txt > path/B.txt
> > git add path/B.txt
> > mv A.txt B.txt
> > git rm A.txt
> >
> > Is this correct?
>
> Here you're copying the content of A.txt as it was in the last (HEAD)
> commit, but from what the poster said he wants the content of A.txt as
> it is staged in the index (that is, there may be staged but uncomitted
> changes).
You took the words right out of my mouth! :)
Yeah, I noticed the problem with using HEAD, but the other problem is
that this would change the contents of the file in the working directory
file, which I don't want. Thus, putting the contents of the file as it
is in the index into the working directory wouldn't be correct either.
In addition, I'm not quite sure where that "mv A.txt B.txt" came from,
since we're supposed to be moving A.txt to path/B.txt...
> > Better:
> >
> > > mv A.txt path/B.txt
> > > Point the index entry for A.txt to path/B.txt
>
> Yes, that is basically what he was asking for, as I read it.
Yep! I was going to respond to your (Michael's) original message saying
exactly that. :)
> El 19/10/2007, a las 5:47, Jeff King escribió:
> > Hrm. So you _do_ want to do an index-only move of A to B, in which
> > case the suggestion of a "git-mv --cached" seems sensible. Though
> > I'm curious why you want that.
>
> I agree that git-stash can be used in this workflow but I can also
> imagine cases where the proposed "git-mv --cached" might be a bit
> nicer.
As Shawn said, --cached wouldn't be entirely accurate as the file in the
working directory is being moved as well.
git-stash has been suggested to me numerous times, but I really feel
that there's no need to use it in this case - if the git mv command gave
adequate control to the user, it would be unnecessary.
> I'm thinking of occasions where you just want to do something
> like:
>
> git mv --cached foo bar
> git add --interactive bar
I think it would be the other way around, since the only time this
change would effect anything is when there are changes still waiting to
be staged.
Are you talking about REALLY only changing the index? I can't think of
why you'd want to do this either... After all, wouldn't there be no bar
file to do git add --interactive on? In addition, I don't think giving
--interactive a filename is meaningful...
> I'm not sure the proposed "--cached" switch should ever be the
> default -- would need to ponder that one -- but I do think the switch
> would be a nice addition.
Yeah, that is one thing I was wondering. It would break compatibility,
but would it be enough to put a note about that in the announcements for
a release? Could you make the change at a release when the interface
isn't guaranteed to be the same, or is this practice only done with
libraries?
It might be interesting to do some sort of survey of whether people
depend on this behavior. It seems pretty inconsistent with how git works
otherwise, and I'd be surprised if a lot of people expect it (kinda like
the Spanish Inquisition :-P).
Thanks,
Ari
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Ari Entlich @ 2007-10-20 5:55 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Witten, git
In-Reply-To: <20071019034704.GB11095@coredump.intra.peff.net>
On Thu, 2007-10-18 at 23:47 -0400, Jeff King wrote:
> On Thu, Oct 18, 2007 at 11:40:47PM -0400, Michael Witten wrote:
>
> > Anyway, succinctly:
> >
> >> What you want to happen is the following:
> >>
> >> git show HEAD:A.txt > path/B.txt
> >> git add path/B.txt
> >> mv A.txt B.txt
> >> git rm A.txt
The one above is not only "worse" than the one below, it's wrong. See
Wincent's message and my response to it.
> >
> > Better:
> >
> >> mv A.txt path/B.txt
> >> Point the index entry for A.txt to path/B.txt
> >
> > I hope that's right.
>
> Hrm. So you _do_ want to do an index-only move of A to B, in which case
> the suggestion of a "git-mv --cached" seems sensible. Though I'm curious
> why you want that.
Well, I also want to move the working directory file so that the index
and the working directory still match up and so that their differences
are preserved. Therefore, --cached isn't quite right (see Shawn's
messages and my response to them).
> The only workflow I can think of is:
> 1. you modify a.c
> 2. your boss comes in and tells you to make some unrelated change,
> which involves moving a.c to b.c
> 3. You don't want to commit your changes, so you git-mv in the index
> only without involving your dirty working tree file.
> 4. You commit the index (which doesn't have your changes from (1)
>
> I think that is sort of a bogus workflow, though, since you will never
> have actually compiled or tested the changes in (2). You are much better
> to git-stash your current work, fulfill the boss's request, then
> unstash.
Hmm, that's an interesting point. Are you talking about situations in
which your changes after (1) leave the program in an uncompilable state?
In this situation, I could imagine git stash being a better solution. In
my situation, however, the project was compilable. The reason I didn't
want to commit the changes was because I wasn't entirely satisfied with
how I implemented the change I was trying to make; I thought there might
be a better way to do it. I wanted to get some comparatively
straightforward changes out of the way before I tackled it.
On some level, the reason I want this change isn't entirely because it's
preventing me from doing something I want to do. I've come to really
like git and how the index can be used to separate all of the changes
you have made from the changes that you want to commit in individual
commits. I've come to really like how much access to the lower-level
interfaces git provides. It seems to me that people should support this
simply because it provides more power to the user. If the user wants
their unstaged changes to be staged, they can explicitly do it with git
update-index or some such command.
If the issue is whether this would be the default, that's a completely
separate issue, and one which I don't really have a strong opinion on.
If it were up to me, I'd probably choose to make it the default, but
this might break some people's expectations. I want to keep git
accessible to as many people as possible, not force it into the mold
that I feel is the only correct one. If the functionality is available
but only used when you want it, what's the harm in including it?
I don't really see why you're analyzing the situations in which this
would be used. I think it should be obvious from my descriptions of my
situation that there is an application for this functionality. Unless
you're going to start calling my process bogus (as you did to the one
involving a boss), which I would not appreciate, I'd argue that the same
mentality should be applied to this that is applied to kernel drivers -
if it's useful to even only one person, it should be supported. This
functionality of git wouldn't even be that extreme an example, though -
there's no telling whether somebody might be in a situation like mine
and find that they want to do what I want to do.
But... that's not even the point I was going to make. I think the
questions you should be asking are things like "Does this fit with the
overall architecture?", "Does this or doesn't this provide power and
flexibility to the user?", etc. Is git being made for "the 80%" that use
Subversion and need to be supported by a cushy GUI, or "the 20%" that
thrive on power and are in touch with future trends?
So... yeah. Sorry, I know this got to sounding incredibly
propagandistic, but this is what propaganda's for, right? :)
Sorry if anything I've said here sounded confrontational; that was not
not my intent at all. I'm just raising some points I think are
important. I don't want any flame wars...
On Thu, 2007-10-18 at 23:58 -0400, Jeff King wrote:
> On Thu, Oct 18, 2007 at 11:53:05PM -0400, Michael Witten wrote:
> > It's not unreasonable.
>
> I guess. I really think git-stash is your friend here. But you can
> still do step (3) with git-update-index (I'll leave the exact details
> as an exercise for the reader).
See my response to Wincent's message for my opinion on using git stash.
I seems to me that using it is more of a workaround than a fix.
Thanks,
Ari
^ permalink raw reply
* Re: git on afs
From: Shawn O. Pearce @ 2007-10-20 5:29 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git, Brandon Casey
In-Reply-To: <200710190742.08174.todd@fries.net>
"Todd T. Fries" <todd@fries.net> wrote:
> It should not matter, but I'm using arla's afs client on OpenBSD; the errno
> is 17 (EEXIST), the very errno that bypasses the coda hack's rename():
...
> I can assure you that the 2nd argument to link does not exist ;-)
...
> The only downside is that either on coda or if the file already exists, it
> will try a spurrous rename(), in which case it will fail with EEXIST again,
> so I hope this is not a big negative.
Actually there is a really big downside. rename() is defined to
unlink the destination if it already exists, so you'll never get
EEXIST from a rename() call.
This means that an existing (known to be good) object can be
overwritten as a result of a rename with another copy of the object.
We've never really had that behavior as part of our security model
has been to always trust what is already in the repository and
refuse to replace something we already have.
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2004,8 +2004,13 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
> *
> * When this succeeds, we just return 0. We have nothing
> * left to unlink.
> + *
> + * AFS hack - afs is similar to coda, but inconveniently
> + * set errno to EEXIST, so call rename() if the link()
> + * above fails unconditionally. Small bit of extra work
> + * so afs functions properly.
> */
> - if (ret && ret != EEXIST) {
> + if (ret) {
> if (!rename(tmpfile, filename))
> return 0;
> ret = errno;
This is very unfortunate. There's no way to tell that the file
already exists. This whole AFS link() returning EEXIST is sort of
like the unlink() call on Solaris UFS working on directories as root
and leaving corrupted filesystems. At some point the application
just cannot be reasonably expected to work on a system that acts
this insane.
I think I would rather change sha1_file.c to write temporary files
into the destination directory, rather than one level up and try to
hardlink them into position. At least there we can rely on hardlinks
within Coda and AFS, and only need this rename special case for FAT.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-20 5:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Sixt, Theodore Tso, Santi Béjar, Shawn O. Pearce,
David Symonds, git
In-Reply-To: <alpine.LFD.0.9999.0710191009330.19446@xanadu.home>
On Fri, Oct 19, 2007 at 10:14:59AM -0400, Nicolas Pitre wrote:
> > ==> git://repo.or.cz/git/spearce.git
> > * (new) gitk -> spearce/gitk
> > * 1aa3d01..e7187e4 maint -> spearce/maint
> > * de61e42..7840ce6 master -> spearce/master
> > * 895be02..2fe5433 next -> spearce/next
> > + 89fa332...1e4c517 pu -> spearce/pu
> > * (new) todo -> spearce/todo
>
> Actually I think this is the best format so far: one line per branch, no
> terminal width issue (long branch names are simply wrapped), the
> old..new info is there also with the single character marker to quickly
> notice the type of update.
Technically speaking, the hash IDs can be up to 80 characters long,
since they are meant to be unique abbreviations. But in practice, I
think leaving enough space for 10 + '...' + 10 should accomodate just
about any project (IIRC, the kernel's longest non-unique is around 9).
-Peff
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Shawn O. Pearce @ 2007-10-20 4:57 UTC (permalink / raw)
To: Jeff King; +Cc: Dan McGee, git
In-Reply-To: <20071020042257.GA26755@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 08:00:37PM -0500, Dan McGee wrote:
>
> > Turns out I didn't have GIT_EXEC_PATH set up right. Once I do that,
> > everything seems to work just fine.
> >
> > Thanks for looking into this Jeff, and git-bisect just won me over. It
> > made easy work of finding the commit that broke this.
>
> Huzzah, success! Shawn, this should probably go on 'maint'. Although it
> is probably not high priority (it has been broken since May; I think
> wildcard push refspecs must not be that common), it is a fairly trivial
> fix that shouldn't impact anyone else.
Yea, its already queued on maint. Both the patch and the
tests are obviously correct. Its broken without the patch.
Its documented/expected behavior fixed by the patch. IMHO it
belongs in maint.
--
Shawn.
^ permalink raw reply
* Re: gitk patch collection pull request
From: Linus Torvalds @ 2007-10-20 4:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18201.34779.27836.531742@cargo.ozlabs.ibm.com>
On Sat, 20 Oct 2007, Paul Mackerras wrote:
>
> Do you mean that when you have a file limit, the diff window should
> just show the diffs for those files, not any other files the commit
> might have modified?
Yes. The same way "git log -p" works by default.
With perhaps a checkbox to toggle the "--full-diff" behaviour.
> That would be easy enough to implement in gitk.
Well, the "--merged" case is slightly trickier, since git will figure out
the pathnames on its own (it limits pathnames to the intersection of the
names you give one the command line *and* the list of unmerged files, ie
the "filter" becomes "git ls-files -u [pathspec]".
But goodie. I look forward to it ;)
Linus
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-20 4:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710191227340.26902@woody.linux-foundation.org>
Linus Torvalds writes:
> The biggest problem I have with gitk is that it is almost totally useless
> for when you have a file limit.
>
> I do "gitk --merge" (which has an implicit file limit of the list
> of unmerged files) or just "gitk ORIG_HEAD.. Makefile" and the *history*
> of gitk looks fine.
>
> But the diffs are crap and useless, because they contain all the stuff I
> did *not* want, and hides all the relevant information.
Do you mean that when you have a file limit, the diff window should
just show the diffs for those files, not any other files the commit
might have modified? That would be easy enough to implement in gitk.
Paul.
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-20 4:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dan McGee, git
In-Reply-To: <449c10960710191800j3e61b80cma2c582080c1dd07c@mail.gmail.com>
On Fri, Oct 19, 2007 at 08:00:37PM -0500, Dan McGee wrote:
> Turns out I didn't have GIT_EXEC_PATH set up right. Once I do that,
> everything seems to work just fine.
>
> Thanks for looking into this Jeff, and git-bisect just won me over. It
> made easy work of finding the commit that broke this.
Huzzah, success! Shawn, this should probably go on 'maint'. Although it
is probably not high priority (it has been broken since May; I think
wildcard push refspecs must not be that common), it is a fairly trivial
fix that shouldn't impact anyone else.
-Peff
^ permalink raw reply
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Shawn O. Pearce @ 2007-10-20 3:19 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071019211152.GN3917@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote:
> > Further, I am surprised that -x seems to be nonfunctional when the
> > cherry pick introduces a conflict. Example:
> [...]
> > The prototype commit message now does not contain the
> > | (cherry picked from commit ...).
> >
> > Is that by design (because there were conflicts) or an omission?
> > In case of the former, maybe the description of -x should mention this.
>
> git commit currently doesn't know that you commit a cherry-pick. The -c
> only says to use the commit message of the original commit. So this is
> currently by design.
Ralf, can you submit an updated version of this patch that describes
the current behavior better, given the "by design" remark above
from Frank?
--
Shawn.
^ permalink raw reply
* Re: gitk patch collection pull request
From: Shawn O. Pearce @ 2007-10-20 3:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18200.36704.936554.220173@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
> Shawn O. Pearce writes:
> > The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
> > Paul Mackerras (1):
> > gitk: Fix bug causing undefined variable error when cherry-picking
> >
> > are available in the git repository at:
> >
> > git://repo.or.cz:/git/spearce.git gitk
...
> > Jonathan del Strother (2):
> > gitk: Added support for OS X mouse wheel
> > Fixing gitk indentation
>
> This one is bogus. Firstly, it doesn't have "gitk:" at the start of
> the headline (and "Fixing" should be "Fix"). Secondly, the actual
> change itself is bogus. It changes an initial tab to 8 spaces on each
> of 4 lines. I like it the way it is - and if he wanted to change it,
> he should have changed it throughout the file, not just on 4 lines.
> So that change is rejected.
>
> The other changes are OK. If you could re-do your tree without
> 0d6df4de (and possible change "Added" to "Add" in e1b5683c while
> you're at it), I'll do the pull.
Done. I also added this one from Michele:
From: Michele Ballabio <barra_cuda@katamail.com>
Subject: [PATCH-resent] gitk: fix in procedure drawcommits
--
Shawn.
^ permalink raw reply
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Shawn O. Pearce @ 2007-10-20 2:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1192823286-9654-10-git-send-email-johannes.sixt@telecom.at>
I've gone through this entire series and am quite happy with it.
Except one bug in this particular patch.
Johannes Sixt <johannes.sixt@telecom.at> wrote:
> We run the sideband demultiplexer in an asynchronous function.
...
> diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> index 871b704..51d8a32 100644
> --- a/builtin-fetch-pack.c
> +++ b/builtin-fetch-pack.c
> @@ -457,42 +457,37 @@ static int everything_local(struct ref **refs, int nr_match, char **match)
> return retval;
> }
>
> -static pid_t setup_sideband(int fd[2], int xd[2])
> +static int sideband_demux(int fd, void *data)
> {
> - pid_t side_pid;
> + int *xd = data;
>
> + close(xd[1]);
If this is a threaded start_async() system this close is going
to impact the caller.
> close(xd[0]);
> - close(fd[1]);
> + fd[0] = demux->out;
> fd[1] = xd[1];
Which is relying on xd[1] right here in the caller. Therefore you
cannot actually use this code with a start_async() implementation
that isn't fork() based. Isn't that going to cause you trouble in
the msysGit tree?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Dan McGee @ 2007-10-20 1:00 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019134339.GA21852@coredump.intra.peff.net>
On 10/19/07, Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 08:38:06AM -0500, Dan McGee wrote:
>
> > origin(junio)/master: 58ba4f6
> > origin(junio)/next: fe96ee67ec5840
> > spearce/master: 7840ce6cb24a9d
> > spearce/next: 2fe5433b416f0df
> >
> > Can you let me know what commit you based the patch off of? I'm at
> > work for the next 8 hours or so, so I can't look in to this a whole
> > lot until tonight.
>
> It is based on Shawn's next, 2fe5433b. Are you sure you're not doing
> something silly like executing an older version of git that is in your
> PATH?
Turns out I didn't have GIT_EXEC_PATH set up right. Once I do that,
everything seems to work just fine.
Thanks for looking into this Jeff, and git-bisect just won me over. It
made easy work of finding the commit that broke this.
-Dan
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-19 23:37 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Jakub Narebski, git
In-Reply-To: <1192827476.4522.93.camel@cacharro.xalalinux.org>
Hi,
On Fri, 19 Oct 2007, Federico Mena Quintero wrote:
> Bash: Display all 150 possibilities?
>
> Beijing hacker: "oh, shit..."
>
> It's hard to know where to begin :) Do I need "git-cherry-pick" or
> "git-cherry"? Why is the "apply a patch" command called "git-am"? Why
> is it different from "git-apply"? From "git-applypatch"? Etc.
Yeah, I was arguing a bit about obsoleting the "git-*" programs. But it
seems that we are not getting it anytime soon.
FWIW try this:
git<Space><Tab>
or even better:
git<Enter>
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-19 23:27 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Johannes Schindelin, git
In-Reply-To: <1192827476.4522.93.camel@cacharro.xalalinux.org>
On 10/19/07, Federico Mena Quintero <federico@novell.com> wrote:
> "Make git more task-oriented rather than data-model-oriented" is about
> making the tool adapt to what you usually want to do, instead of making
> *you* adapt to the way the tool wants to work. Many commands in Git
> have documentation like
>
> "option --foo updates the refs without modifying the index. Requires
> a clean working tree"
>
> This is gibberish for people who are not very familiar with Git's
> internals. "Git for computer scientists" provides a *very nice*
> explanation of the DAG and refs and tags, but unfortunately it doesn't
> explain the index, why you would want to know about it, etc.
That is what "Git User's Manual" (and tutorials) is for. And there is
glossary in documentation.
[...]
> It's nice that Git lets you manipulate the repository in all kinds of
> ways, but presenting porcelains at the same level as plumbing makes
> things hard for users to learn. I was just in our Beijing office,
> teaching people about development tools and Git in particular.
>
> Federico: "get Git from this location"
>
> Beijing hacker: tap tap tap, "okay, it's installed now"
>
> Federico "Git commands all start with 'git'"
>
> Beijing hacker: git<Tab>
>
> Bash: Display all 150 possibilities?
>
> Beijing hacker: "oh, shit..."
It is better to use bash (or zsh) completion, than rely on completion
of commands names.
Beijing hacker: git <Tab>
(that is, space after 'git') shows around 62 commands.
> It's hard to know where to begin :) Do I need "git-cherry-pick" or
> "git-cherry"? Why is the "apply a patch" command called "git-am"? Why
> is it different from "git-apply"? From "git-applypatch"? Etc.
I think git-cherry will soon be obsoleted and removed, such like
git-applymbox and it companion git-applypatch are being obsoleted by
git-am.
git-am applies series of patches _with description_ from messagebox,
creating commits if patch applies without conflicts. It requires git
extended patch for sensible operation; it is best when patch is result
of git-format-patch. git-apply is to apply GNU patch (optionally git
patch) to working area, or working area and index, but do not create a
commit. It is improved version of GNU patch utility (it understands
git extended diff syntax), but it is not meant (alone) to work with
commits send by email.
--
Jakub Narebski
^ permalink raw reply
* Fourth incarnation of the msysGit herald
From: Johannes Schindelin @ 2007-10-19 23:25 UTC (permalink / raw)
To: msysgit, git
Good morning git land!
20 years after the black monday, which happens to be exactly three days
after the 164th (official) birthday of the quaternions, is as good an
occasion as any to bring to you the fourth incarnation of the msysGit
Herald, the not-quite-biweekly news letter to keep you informed about
msysGit, the effort to bring one of the most powerful Source Code
Management systems to the poor souls stuck with Windows.
These are the covered topics:
Spanking new Inno installer
New naming scheme & new release
git gui
Interview with Steffen Prohaska
Calling git from cmd.exe
Historic notes
Spanking new Inno installer
===========================
As mentioned in the last Herald, Sebastian Schuberth (with some help
of Steffen Prohaska) started to replace the 7-Zip installer that I
built with my heart and soul. I even came so far as to work around
Windows' refusal to delete the uninstaller while that is running
(which would usually be its last action on other platforms).
Incidentally, this uninstaller was also a nice small example how to
write an elegant Win32 program without bloat. My opinion _might_ be
biased because I wrote it.
But I have to admit that the installer based on Inno looks sleeker,
more professional, and is easier to extend.
It uses the same LZMA compressor that 7-Zip used, so there is (almost)
no downside regarding the size of the installer.
The usual options, such as adding a Start Menu, a Quick Launch item,
a Desktop item, a simple Explorer extension, and an uninstaller,
come basically for free with Inno. Well, not exactly for free, but
Sebastian did all the hard work, so that we all could benefit.
>From what I hear, this installer is also able to run on DOS based
Windows such as Windows 95. Yeah!
The downsides of using Inno that I have encountered so far are not
important in comparison:
You can no longer just unzip the installer with 7-Zip. But if that
should turn out to be a major problem for many people (which I doubt),
we can still just add one line to automatically generate a .7z file
at the same time as the installer. I came upon a little project
named "innounp" (on sourceforge.net), though, which purportedly unpacks
installers made with Inno Setup. Maybe at some stage there is also
a 7-Zip plugin ;-)
The installer was easily built using Linux, by making a 7-Zip archive
and prepending the self-extracting module and the config file. Well,
Wine is not there yet, but hopefully it will soon.
The installer does not run under Wine. But then, neither did the
7-Zip based installer.
New naming scheme & new release
===============================
There was a bit of a stir when we realised that not everybody
understands the differences between GitMe, msysGit and WinGit.
So we sat down on the msysgit list and thought about it a bit.
There are basically two different projects: msysGit, which is the
development environment which is needed to compile git and friends.
And there is the installer which delivers the compiled programs to
those who do not want to work _on_, but _with_, git. We used to
call this WinGit (I liked it very much because of the connotation
of "to wing it").
But Steffen Prohaska pointed out, rightfully so, that it should be
Git-<version-and-stuff>.exe.
Since our current versions are not as smooth-running as git on
POSIX platforms, we decided to go with the "preview" postfix, until
we are reasonably comfortable to declare it "beta". Note: in the
good tradition of Open Source, our "preview" versions are probably
more usable than some XP^WGolden versions of commercial software.
The version number will be that of the git release we are basing
our installer on, and we plan to have indicators "rc<n>" once our
project is stable enough that we are reasonably certain that it
does not have fatal flaws. Also, the timestamp of its build will be
part of the file name, and we will tag the exact state in msysgit.git
which this build was based on.
So we now have the first official preview of Git on MSys. By the old
naming scheme, this would have been "WinGit 0.3 alpha".
It was created with Inno (see previous story), and we expect the user
experience to be much smoother than with previous releases. There is
one known issue, though: pull/fetch does not work in git gui (also see
next story).
git gui
=======
git gui is a really nice program, and as I often said, I consider it
more porcelain than a gui, since it uses the git core directly, instead
of wrapping around porcelain commands.
The user experience I had with git gui made me think that this should
be the primary interface Windows users should be confronted with, not
the command line.
The major problem we had in msysGit is that git-gui was to be launched
from the Start Menu, or a QuickLaunch icon. This is in contrast to
the shell, where you usually start git gui in a working directory.
So we needed some method to choose a working directory. Mike Pape
put some work into that, but got too much work to do with the day
job. While he was busy with non-gittish things, Shawn Pearce went
busy writing a wizard to select an existing directory, create a new
one, or clone a repository.
One issue we did not yet properly resolve is that fetch/pull does not
work from within git gui. For the moment, you have to use the Git bash.
I suspect that this issue will disappear automagically when we merge
with newer git which have the builtin fetch.
Steffen Prohaska contributed the "open recent" feature, so there is
nothing left preventing our taking over the (Windows-)world!
Interview with Steffen Prohaska
===============================
> 1) How did you get involved with Git?
I was looking for a simple version control system to handle my personal
Mac OS X documents. Mac OS X applications save data as directories
containing related files that together form a document. A version
control system must not store data in such a directory.
I worked with CVS, which I am still using on a daily basis, and tried
svn. But both need to store data in every subdirectory they manage.
I stumbled over a couple of other systems, like monotone, arch, darcs,
and finally git. Git was quite easy to install and did what I needed;
well, after I found out about
git-ls-files -z --others SomeBundle | \
git-update-index --add -z --stdin
git-commit -a
I created my first git repository around April 2006 and have these two
lines in a script there. And I still use them to handle nearly all of
my documents.
> 2) What were the reasons that you started working on Git?
Git did always a great job managing my own documents. But two
deficiencies kept me for a long time from advertising it as a
replacement for our CVS: Git didn't work on Windows and git didn't
provide a mechanism that is today known as sub-modules.
When it turned out that sub-modules will become available and Windows
support (autocrlf) was introduced, I started to evaluate a migration
of our development team from CVS to git. The need for a new system
intensified after it became clear that we'll have to handle three
sub-groups in the future with different release schedules.
I was pretty convinced that git would be the right system. But Windows
support was just not good enough. So I started to work on this.
A bit earlier I needed to debug CVS import. If I remember correctly
the first patch I sent was on git-cvsexportcommit.
> 3) What do you like most in Git?
When I started I liked most the lightweight installation and easy
setup of fresh repositories.
Today, I like most the great support for automatic merging, rerere,
and git-mergetool.
> 4) What do you hate most in Git?
Git asks me two times for my password during 'git fetch' when I
forgot to unlock my ssh-key. And I can't reasonably explain this
fact to newbies.
I often need to find small workarounds for minor deficiencies in
the user interface. Especially getting started with git is not as
easy as it could be. git-* matches approximately 150 commands.
That's overwhelming.
> 5) What was the most surprising moment when working with Git?
When I learnt about rerere. It's magic.
> 6) What was the most frustrating moment when working with Git?
When I understood that git-cvsimport messes up CVS history and
cannot be used for importing from CVS. It was really hard to find a
working alternative. The documentation didn't help much.
I was also quite desperate when I understood that git will never
run in Cygwin's textmode.
> 7) In what environment do you work?
Mac OS X, Linux (x86_64, i386, ia64), XP, XP64, Vista.
> 8) What other hobbies do you have?
besides git? ... hmm ... maybe jogging counts as a hobby.
> 9) What is your favourite movie?
Pulp Fiction.
> 10) What are your visions for Git? (I.e. where do you want it to go?)
I wish to see all core features with same quality on Windows as on Unix.
In addition, everything which is needed to support cross-platform
projects that look on Windows as if they were pure Windows projects and
on Unix as if they were pure Unix projects.
A leaner user interface would be nice that is more focused on the
essential workflows and makes it easier to explain git. The average
developer shouldn't need to know too many details about git before he
is able to participate in a shared repository workflow.
Steffen
Calling git from cmd.exe
========================
As mentioned in the story "The war between cmd and bash" in the first
issue of this little tabloid, some people prefer to avoid bash.
The simplest solution to allow this would be to add msysGit's bin/
to the PATH. Alas, it is not as easy as that.
Windows has its own versions of "sort" and "find", and regular Windows
users' scripts might rely on finding those, while git relies on finding
more POSIXy versions of those programs.
Therefore we have a cmd/ directory containing wrappers for git and gitk,
and the new installer adds this directory to the PATH. (Actually you
can choose between a few different options...)
That should make everybody happy.
Historic notes
==============
Reading Jakub's results of the git survey instigated me to investigate
when msysGit was born (under a different name...). We had a tremendous
progress since, and it almost felt as two years had gone by since I
started this thing.
Alas, the first commit I ever made on my mingw branch was on
Tue Jun 20 19:13:02 2006 +0200
A long time nevertheless. From the commit messages I found that the
first time I fixed a test -- which is my best indicator that I got
something running; I did not manifest a "Hooray, first time it
_does_ something" in any commit message -- was on
Tue Sep 19 15:11:29 2006 +0200
So it took me two months, on and off, to get it to run. Of course, this
version was so lousy that it was only barely self-hosting. Since I could
not get vi to run on my MinGW setup, I did the commits using -m.
I also had not found out yet that bash in an Rxvt was not able to call
"less" properly, and I had to pipe "git log | less" to stop the output
from whizzing by as fast as Douglas Adams' deadlines.
Reading further in my logs, I stopped working on my mingw branch on
Wed Sep 20 17:38:35 2006 +0200, certainly because I did not feel the
need, and the major obstacles had been tackled, and I got bored with it.
Or my boss made me work for a change. Something along those lines.
All the better for the many eager Windows users that Hannes Sixt took
up the ball, and committed his first version on Fri Dec 22 11:43:50
2006 +0100, although you can see in the logs that it was recommitted
(for the last time, I guess) on Fri Jan 19 16:21:41 2007 +0100.
Since then, he made steady progress, with a few helpers helping out
from time to time.
The next big turn was the kick off of the msysGit project... the rest
is history.
^ permalink raw reply
* RE: linux-2.6.git mirror
From: Medve Emilian-EMMEDVE1 @ 2007-10-19 22:50 UTC (permalink / raw)
To: Linus Torvalds, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710181617090.26902@woody.linux-foundation.org>
Hi Linus,
> And yes, I think this should go into Shawns tree of fixes,
> assuming that
> Emil confirms that it fixes it for him.
Indeed, I don't get the error message anymore. Thanks for your help.
A remaining question is why I wasn't seeing that error message on normal
clones, i.e. non-mirrors (with +refs/heads/*:refs/remotes/origin/* fetch
refspec as oposed to +refs/*:refs/* fetch refspec)?
Thanks again,
Emil.
^ permalink raw reply
* RE: git push bug?
From: Johannes Schindelin @ 2007-10-19 22:46 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: 'Steffen Prohaska', 'git'
In-Reply-To: <000001c81280$ebc5c5e0$5267a8c0@Jocke>
Hi,
On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
> > From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> >
> > On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
> >
> > > On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> > > >
> > > > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> > > >
> > > > > First, I didn't know that I could do that. Secondly, I was also
> > > > > looking do v2.6.23:linus refspecs
> > > >
> > > >
> > > > First, then our documentation could be better. How?
> > >
> > > Well, it isn't clear to me how all this is supposed to work and what
> > > is bugs. Clearifying that would help.
> > >
> > > For instances I did a push with v2.6.23:refs/heads/linus and now I
> > > got a branch with the SHA1 of v2.6.23
> > > tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d) in it. Makes gitk
> > > display that branch as "linus^{}".
> >
> > It strikes me as really odd that you would _want_ to create a branch
> > remotely, that has _never_ existed locally.
>
> It strikes me as really odd that a core developers like yourself
> hasn't tried to justify/explain why push works as it does.
Well, I explained that I think the "src:dst" way to specify things are not
meant for git newbies. Don't use it.
git push <remote> <branchname> works exactly as advertised. It pushes the
specified branch to the remote repository.
> As I am trying to convince our dev. group here to move to git instead of
> subversion, I need to learn how git works. Now I have gotten to the push
> function and I need to know what can be done with push and how, pitfalls
> too. As I go along I find behavior that I find odd and report these to
> the list.
>
> git push <repo> v2.6.23:refs/heads/linus
> will make a tag look like a branch
Don't use src:dest notation.
> git push <repo> linus:linus
> won't let me create the remote branch linus
Don't use src:dest notation.
> but
> git push <repo> linus
> will
Use this. This is good.
> git push <repo> :linus
> OOPS, now I just deleted remote branch linus, no warning
Don't use src:dest notation.
> git push <repo> linus:refs/head/linus
> creates a branch that is invisible(wont show in git branch -a)
Don't use src:dest notation.
> git push <repo> linus:refs/heads/newbranch
> creates remote branch newbranch, but you have to know the magic words
> refs/heads/ to do it.
Don't use src:dest notation.
> Se what I mean?
Yes.
I hope you return the honour.
> > > > Second, why not "git checkout -b linus v2.6.23 && git push origin
> > > > linus"?
> > >
> > > An extra checkout that takes time but works.
> >
> > Not only that: before trying to publish something, I would have
> > expected you to have that branch locally, and that you actually worked
> > on it.
> >
> > > Doesn't make the above "weiredness" go away though.
> >
> > Yes it does.
>
> No it doesn't. If someone else in my group wants to create a branch they
> might do the same mistakes as I did.
Yes, it does. You no longer can push a tag onto a remote branch by
accident. Just don't use the src:dest notation. Forget about it. You
definitely don't need it before you understand git better.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Theodore Tso @ 2007-10-19 21:58 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Karl Hasselström, Santi Béjar, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710191739270.19446@xanadu.home>
On Fri, Oct 19, 2007 at 05:40:48PM -0400, Nicolas Pitre wrote:
> No. "next" is the name of the _remote_ branch that is stored locally in
> spearce/next. So the arrow is correct.
Ah; yes, you're right. I can see this being very confusing to the
newbie, though. Enough so that in beginner mode we might want it to
say:
895be02..2fe5433 (remote) next -> (local) spearce/next
... especially since the git pull might follow up the pull with a
merge from the local remotes/spearce/next to the local next branch.
So it would be a good idea that it is clear when we are referring to a
local or a remote branch.
- Ted
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Linus Torvalds @ 2007-10-19 21:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710191157560.26902@woody.linux-foundation.org>
On Fri, 19 Oct 2007, Linus Torvalds wrote:
>
> Could be done, but I almost think it would be better to just make the
> sha1_name.c interfaces take some extended data structure which allows
> looking up multiple SHA1's at the same time.
Btw, I knew I had wanted this in the past, but I had forgotten why. I now
remembered.
The thing is, sometimes you want an expression for "all the parents of X".
We don't have that, and again, the current internal implementation of
sha1_name.c makes it essentially impossible to do within that interface
(ie you can do it on *top* of that interface in revision.c, but it cannot
be a general SHA1 expression).
So wouldn't it be nice to have a "commit^*" expression to go with
"commit^" and "commit^2" etc? One that would name all the parents. It's
useful, for example, for saying that you still want to see that commit,
but not any of its parents:
git log commit^*..
could basically work to show that commit (and all subsequent commits), but
not the commits leading up to it. Right now, you can't easily say that in
the git "sha1 expression algebra".
There are some other cases where you'd like to have things expand to more
than one commit. We currently do those with special flags, like --all, but
in many ways it would be really nice to be able to do SHA1 operations on
them. If we were to make the SHA1 arithmetic able to handle multiple
SHA1's (instead of just one), I could see us being able to do things like
git diff {master,pu}:Makefile
as a way of saying
git diff master:Makefile pu:Makefile
which already works - simply because we could make the ":name" be able to
operate on multiple commit SHA1's and turn them into multiple blob (or
tree) SHA1's.
(The above may not sound very useful, but
git diff {ORIG_HEAD...MERGE_HEAD}:file
would essentially expand to "base version of file", ORIG_HEAD:file and
MERGE_HEAD:file, and we could fairly easily teach diff to do a nice
three-way diff for things like this! So it does have potential to be a
reasonably powerful model)
Linus
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 21:40 UTC (permalink / raw)
To: Theodore Tso
Cc: Karl Hasselström, Santi Béjar, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <20071019211755.GC751@thunk.org>
On Fri, 19 Oct 2007, Theodore Tso wrote:
> On Fri, Oct 19, 2007 at 11:03:00AM -0400, Nicolas Pitre wrote:
> > Well, the important thing is that the _content_ is moving from the
> > remote repository to the local one. That's how the arrow should be
> > interpreted conceptually. The fact that technically we end up assigning
> > the local ref with the remote value is a technical issue.
>
> If the _content_ is moving from the remote repository to the local
> one, I would think the arrow should be pointing from the remote
> repoistory to the local one, i.e.:
>
> * 895be02..2fe5433 next <- spearce/next
>
> But right now we are proposing:
>
> * 895be02..2fe5433 next -> spearce/next
>
> I would think the former makes more sense is the content is going
> *from* spearce/next into the local next branch.
No. "next" is the name of the _remote_ branch that is stored locally in
spearce/next. So the arrow is correct.
Nicolas
^ permalink raw reply
* Re: Git-submodule questions
From: Linus Torvalds @ 2007-10-19 21:30 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710191420410.26902@woody.linux-foundation.org>
On Fri, 19 Oct 2007, Linus Torvalds wrote:
>
> In fact, it should be enough to do
>
> cd /srv/DM
> git init
> git add .
> git commit
>
> and you're now literally all done!
.. btw, when I say that, I guess I'm lying a bit.
Yes, the above will actually generate a valid git superproject repository,
but it won't generate/populate the necessary .gitmodules stuff. You'd need
to add it by hand.
But yes, if you want to avoid doing that hand-editing, you should use the
whole "git submodule add .." thing to clone the git repos you already have
into a supermodule. But the .gitmodules thing really is pretty simple, you
just do something like
[submodule "x"]
path = x
url = official-url-of-x
[submodule "y"]
path = y
url = official-url-of-y
and now you just do "git submodule init" and you should be all done
(again, the "git submodule init" thing you could do by hand by editing
the .git/config file, but since you can do it automatically in-place,
there's no real point).
Linus
^ permalink raw reply
* Re: Git-submodule questions
From: Linus Torvalds @ 2007-10-19 21:22 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <428b865e0710191354v59f558bbv4536d60902977ac@mail.gmail.com>
On Fri, 19 Oct 2007, Evan Carroll wrote:
>
> I've got a set of 5 git repositories on one computer. I'm looking for
> a way to more cleanly distribute them, and keep them in sync when i
> distribute them. I'm trying to discern whether the scantly documented
> git-submodule can accomplish this...
Sounds like subprojects are indeed a good way for you.
> All of my git modules are in one place, /srv/DM: /srv/DM/a ..
> /srv/DM/e to add them all into one super repository for easier
> distributing I have to move them all to /srv/DM/git-old, then git init
> in /srv/DM, then I git submodule add all of the modules in
> /srv/DM/git-old. The question then comes down to why do I need to have
> my git-submodules in /srv/DM, and /srv/DM/git-old.
You shouldn't need to do anything even half-way complicated like that.
In fact, it should be enough to do
cd /srv/DM
git init
git add .
git commit
and you're now literally all done!
Linus
^ 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