* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Nanako Shiraishi @ 2008-12-18 3:34 UTC (permalink / raw)
To: Tim Visher; +Cc: Junio C Hamano, git
In-Reply-To: <c115fd3c0812171722g93dbeefw2fb5bf7641dfe394@mail.gmail.com>
Quoting "Tim Visher" <tim.visher@gmail.com>:
> On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> How about omitting the "git commit" and do "git checkout PATH" after you
>> are done with the staging? IOW, (1) above.
>
> Huh. I guess I was under the impression that doing the `git checkout
> PATH` would destroy the staged content as well as the unstaged. This
> isn't the case?
A short answer is "no it is not the case."
I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.
This is a patch to clarify the sentence.
-- 8< -- Cut Here -- 8< --
Subject: Clarify documentation of "git checkout <tree-ish> paths" syntax
The SYNOPSIS section of the manual writes:
git checkout [options] [<tree-ish>] [--] <paths>...
but the DESCRIPTION says that this form checks the paths out "from the
index, or from a named commit." A later sentence refers to the same
argument as "<tree-ish> argument", but it is not clear that these two
sentences are talking about the same command line argument for first-time
readers.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 168333a..bbdfa40 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -27,7 +27,7 @@ the first namespace level.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
-the index file, or from a named commit. In
+the index file, or from a named <tree-ish> (most often a commit). In
this case, the `-b` options is meaningless and giving
either of them results in an error. <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git-diff should not fire up $PAGER, period!
From: Jeff King @ 2008-12-18 3:31 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763lixyps.fsf_-_@jidanni.org>
On Thu, Dec 18, 2008 at 05:45:35AM +0800, jidanni@jidanni.org wrote:
> Gentlemen, I have found the solution to your problem.
>
> Unbundle git-diff and $PAGER.
If you are going to argue this, please at least go back and read the
numerous times it has been brought up in the past on the list archive.
The last discussion ended up showing that some people really like the
automatic pager for some commands, and some people really detest it.
So I implemented 4e10738 (Allow per-command pager config, 2008-07-03),
and now you can do:
git config pager.diff false
and be happy (or, as you obviously disocvered, simply unsetting
core.pager will disable all).
-Peff
^ permalink raw reply
* Re: [PATCH] gitk: force focus to main window
From: Jeff King @ 2008-12-18 3:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Mackerras, Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812180413240.14632@racer>
On Thu, Dec 18, 2008 at 04:14:25AM +0100, Johannes Schindelin wrote:
> > At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> > is a windows thing, isn't it?)
>
> Yeah, because on other platforms, when you start gitk, you don't want it
> to take focus. Yeah, right.
That is _exactly_ what I want on my platform: no window should steal the
focus when I am in the middle of typing in some other window. And to
that end, my window manager does not shift the focus until I tell it to
do so.
So yes, this patch _does_ break at least my setup. But more importantly,
it is an application making a decision about focus policy that should be
made by the window manager. I understand that the window manager in
Windows sucks, and that this is a workaround that makes things better
there. But please don't inflict this braindeadedness on the rest of us.
-Peff
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Johannes Schindelin @ 2008-12-18 3:22 UTC (permalink / raw)
To: Mike Coleman; +Cc: git
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>
Hi,
On Wed, 17 Dec 2008, Mike Coleman wrote:
> I still find git-diff's unsolicited invocation of $PAGER a bit
> jarring, but I also find that I like it.
It might have its reason in that it follows the common flow, where
interactive use of _any_ diff program is _just useless_ unless piped to a
pager.
And no, redirecting to a file is not interactive.
Can we please stop with those bogus and pointless, not to mention
uninformed, discussions about design decisions that have been verified to
be useful, or at least not harmful in any way, for a _long_, _long_ time?
The git list is high volume already, but at least so far it was high
signal/noise ratio.
Let's keep it that way,
Dscho
^ permalink raw reply
* Re: rsync deprecated?
From: Junio C Hamano @ 2008-12-18 3:20 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812180041.10312.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> in the "Merging external work" section of the gitcore-tutorial it is
> stated that the rsync transport is deprecated. The description was added
> in commit 914328a (Update tutorial., 2005-08-30) together with the
> "deprecated" note. Having never heard/read this before and since this
> commit is quite old, I wonder if it is still the case or there was a
> solution for this problem.
Sorry, I do not quite understand what you perceive as "this problem".
It has been deprecated for too long a time. Maybe it is time to remove
the support, instead of carrying the deprecated command forever? Is that
the problem you are talking about?
I tend to agree that rsync transport way outlived its usefulness, and not
maintained at all. There may be unnoticed and undiagnosed bugs lurking,
but nobody knows about it because nobody uses it.
But the next release (1.6.1) won't be a good timing for removal. Perhaps
we can make an announcement now that it will be removed in a future major
update, and actually remove it in 1.7.0 or so.
^ permalink raw reply
* Re: Git - index-pack missing
From: Jeff King @ 2008-12-18 3:16 UTC (permalink / raw)
To: Michael Boutros; +Cc: git
In-Reply-To: <54F47863-AF55-4FB7-8A43-A4253E1F782C@michaelbutros.com>
On Wed, Dec 17, 2008 at 06:40:40PM -0500, Michael Boutros wrote:
> I'm trying to clone a repository for the first time on a hosting account
> that just got setup with Git. However, the problem is that for some reason
> there is no git-index-pack. I cannot find any reason that that one
> particular command would not be installed, but for some reason that seems
> to be the case.
How did you install git? From a binary package, from a tarball, from a
clone? If built, how did you build it? Any config.mak options, did you
use ./configure, etc? What version of git is it?
Is it possible for you to strace the clone process to see where it is
trying to find index-pack? Something like:
strace -f -e execve git clone
should do it.
> Has anyone ever heard of anything like this? Is my only option to
> completely scrap Git and try again?
That might work, but if this is a bug in the build or installation
system, it will be nice to track it down before you scrap the current
setup.
-Peff
^ permalink raw reply
* Re: [PATCH] gitk: force focus to main window
From: Johannes Schindelin @ 2008-12-18 3:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <18761.29020.237388.687560@cargo.ozlabs.ibm.com>
Hi,
On Thu, 18 Dec 2008, Paul Mackerras wrote:
> Johannes Sixt writes:
>
> > On msysGit, the focus is first on the (Tk) console. This console is
> > then hidden, but keeps the focus. Work around that by forcing the
> > focus onto the gitk window.
>
> Hmmm, I don't like doing focus -force unconditionally on all platforms.
> I hate it when applications decide they know best and override what the
> window manager decides.
>From my previous experience with my patches to gitk, I did not expect
otherwise. That is why I did not even bother with this one.
> At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> is a windows thing, isn't it?)
Yeah, because on other platforms, when you start gitk, you don't want it
to take focus. Yeah, right.
Ciao,
Dscho
^ permalink raw reply
* Re: Git - index-pack missing
From: Junio C Hamano @ 2008-12-18 3:15 UTC (permalink / raw)
To: Michael Boutros; +Cc: git
In-Reply-To: <54F47863-AF55-4FB7-8A43-A4253E1F782C@michaelbutros.com>
Michael Boutros <me@michaelboutros.com> writes:
> I'm trying to clone a repository for the first time on a hosting
> account that just got setup with Git. However, the problem is that for
> some reason there is no git-index-pack. I cannot find any reason that
> that one particular command would not be installed, but for some
> reason that seems to be the case.
You may want to study output from "git help --all" to see if there is
anything *else* that is missing. You did not say which version of git you
use, and how it was built and installed with which non-standard options
and in what way, so it is hard to guess what is going on.
Perhaps:
$ cd ~root
$ grep 'rm .*index-pack' .history .bash_history
could help locating the cause of breakage, but there are other ways to
break your installation, so...
> Has anyone ever heard of anything like this?
Not me.
^ permalink raw reply
* Re: Git Notes idea.
From: Johannes Schindelin @ 2008-12-18 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Govind Salinas, Git Mailing List
In-Reply-To: <7voczaobhb.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 17 Dec 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ... But the main point still stands: you go from commit to note, not
> > from note to commit. And this is in stark contrast to tags, where you
> > go from tag to commit, _not_ from commit to tag.
> >
> > That is a fundamental _difference_ between tags and notes, so that I
> > refuse to accept the notion of notes being a generalized form of tags.
>
> Hmm, how would you explain things like "git describe" (and "name-rev")?
Programs?
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Junio C Hamano @ 2008-12-18 2:26 UTC (permalink / raw)
To: Mike Coleman; +Cc: git
In-Reply-To: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com>
"Mike Coleman" <tutufan@gmail.com> writes:
> To me, the most important nugget from the original complaint was that
> git-diff sends its error messages to stdout. I understand why it
> might be done, but I'd worry about losing the stderr diagnostic for a
> command that matters. [I've been playing around with this for a few
> minutes trying to see errors going to stdout and I can't reproduce
> it--I wonder if they really do.]
They indeed did but it has hopefully been fixed. See a833502 (pager: do
not dup2 stderr if it is already redirected, 2008-12-15).
> ... Like Junio, I also eschew doing terminal emulation
> inside of emacs.
Come to think of it, it may have been from you that I picked up the trick
of setting PAGER to cat inside an Emacs environment.
> Good evening from the icy midwest,
Good evening from rainy and chilly SoCal.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Mike Coleman @ 2008-12-18 2:18 UTC (permalink / raw)
To: git
It's so cold here my car wouldn't start this morning, so I feel
fortunate to have these flames to keep me warm! :-)
I still find git-diff's unsolicited invocation of $PAGER a bit
jarring, but I also find that I like it. It has a sort of Windows-ish
feel to it (am I straying from the true path?). It's convenient,
though honestly "git-diff|l" would only be two extra characters. From
a UI perspective, the oddest thing about it is that all (not, in
fact?) of the other git programs which might also produce lengthy
output *don't* invoke $PAGER--git-status particularly comes to mind.
There are a large number of Unix programs that would be more
convenient if their output was automatically paged, but I'm not sure
it'd be better if they were all changed to do this. (The best analog
I can think of where this seems desirable is man(1).)
To me, the most important nugget from the original complaint was that
git-diff sends its error messages to stdout. I understand why it
might be done, but I'd worry about losing the stderr diagnostic for a
command that matters. [I've been playing around with this for a few
minutes trying to see errors going to stdout and I can't reproduce
it--I wonder if they really do.]
Regarding the emacs complaint, as an emacs user I'd say I'm not
surprised this didn't quite work right. In the particular case of the
compilation buffer, I wonder if the solution isn't to just unset TERM,
the existence of which (together with the fact that there's a pty)
could be taken as an invitation for the subordinate process to start
doing awful raw-terminal things. (Similar logic applies to the
DISPLAY variable.) Like Junio, I also eschew doing terminal emulation
inside of emacs.
Good evening from the icy midwest,
Mike
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Frank Li @ 2008-12-18 1:57 UTC (permalink / raw)
To: Tim Visher; +Cc: Henk, git
In-Reply-To: <c115fd3c0812171204ve560583w4c76aac0ac08d8ae@mail.gmail.com>
Great Work!
TortoiseGit start late. But it reuse many TortoiseSVN work.
I believe TortoiseGit can catch.
Best regards
Frank Li
2008/12/18 Tim Visher <tim.visher@gmail.com>:
> On Wed, Dec 17, 2008 at 2:06 PM, Henk <henk_westhuis@hotmail.com> wrote:
>>
>> This is a shameless announcement of my latest personal project; Git
>> Extensions. Git Extensions is a Tortoise-like windows shell extension for
>> git. Yesterday I finished version 0.9, the first stable release. I included
>> about all git commands I know about, so I think it is pretty complete but
>> I'm open to suggestions.
>
> Nice! With all of this TortoiseGit-like activity we're bound to have
> something pretty usable pretty quickly! :) I'll have to check out the
> sources soon and see if I can get involved. Maybe any of the
> developers who were planning on working on TortoiseGit could
> officially move over to Git Extensions since it seems to be much
> further along?
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Tim Visher @ 2008-12-18 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpvajtmd.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> How about omitting the "git commit" and do "git checkout PATH" after you
> are done with the staging? IOW, (1) above.
Huh. I guess I was under the impression that doing the `git checkout
PATH` would destroy the staged content as well as the unstaged. This
isn't the case?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johan Herland @ 2008-12-18 1:00 UTC (permalink / raw)
To: git; +Cc: Gili Pearl, Johannes Sixt
In-Reply-To: <897592.56642.qm@web112219.mail.gq1.yahoo.com>
On Wednesday 17 December 2008, Gili Pearl wrote:
> > From: Johan Herland <johan@herland.net>
> > On Wednesday 17 December 2008, Gili Pearl wrote:
> > > But what if K-L-M conflict with C-D? The one who should take care
> > > about it is the mid-level1 maintainer (or possibly one of the
> > > low-level1 maintainers).
> >
> > If there is a merge conflict, mid-level1 maintainer will typically
> > merge D and M into a new merge commit N:
> >
> > top-level : A----B----C----D
> > \ \
> > \ \
> > mid-level1: K----L----M----N
>
> There's one thing that still bothers me and I'd like to understand.
> What if someone looks both on top-level repo and mid-level1 repo, and he
> want to diff some local commit X against commit D. I didn't try it, but I
> wonder how git knows against which D to compare? On the top-level D means
> A-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what
> git-log on mid-level shows). I'm probably missing something here...
> commit id cannot represent two different histories, right?
D will always be the same commit in both top-level repo and mid-level1 repo.
Remember that D precedes the merge commit N, so D is not changed by the
merge at all (then we could no longer call it D).
The diagram above is slightly misleading, in that it does not say whether
the merge commit N has been pulled into the top-level repo or not. Here are
more descriptive illustrations:
A) Before the merge:
A----B----C----D <-- top-level
\
\
K----L----M <-- mid-level1
B) After mid-level1 has done the merge
A----B----C----D <-- top-level
\ \
\ \
K----L----M----N <-- mid-level1
C) After top-level has pulled the merge from mid-level1 (assuming top-level
has done nothing in the meantime, and can fast-forward to N)
A----B----C----D
\ \
\ \
K----L----M----N <-- mid-level1 & top-level
> > ...and then ask top-level maintainer to merge N (which should have no
> > conflicts by now). The merge can also be done by low-level1 developer.
>
> How can it be done by low-level1? you mean by bypassing mid-level and
> merging top-level directly?
No. low-level1 will do the merge commit in his repo (typically by creating a
new branch at M (thus keeping X & Y out of the way), and then merging D
into this new branch to produce N), and will then ask mid-level1 to pull
the merge into her repo. From there, the situation is similar to the above
diagrams.
In principle, it's possible for low-level1 to ask top-level directly to pull
his merge commit, but this is probably frowned upon, because it breaks the
project conventions (although git itself has no problem with this).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Geoffrey Lee @ 2008-12-18 0:53 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229540813648-1669264.post@n2.nabble.com>
On Wed, Dec 17, 2008 at 11:06 AM, Henk <henk_westhuis@hotmail.com> wrote:
>
> This is a shameless announcement of my latest personal project; Git
> Extensions. Git Extensions is a Tortoise-like windows shell extension for
> git. Yesterday I finished version 0.9, the first stable release. I included
> about all git commands I know about, so I think it is pretty complete but
> I'm open to suggestions.
I'm curious... How are you dealing with Windows' low limit on icon
overlay handlers? TortoiseSVN already hits the system limit, hence
their development of TortoiseOverlay to provide a common icon overlay
handler for all the Tortoise* projects. Have you gotten GitExtensions
to work side-by-side with TortoiseSVN? You might want to take a look
at this document, username "guest" and no password:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseOverlays/Documentation.txt
-Geoffrey Lee
^ permalink raw reply
* Re: [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int
From: Robin Rosenberg @ 2008-12-18 0:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081217224844.GK32487@spearce.org>
onsdag 17 december 2008 23:48:44 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > If not dates past 2038 will be parsed the wrong way when
> > parsed into a RevCommit or RevTag object.
>
> Uhm, sure.
>
> But there's also the commitTime field in RevCommit, its used to
> sort commits during walking. In 2038 that will also overflow.
Ok, but that's not used for display purposes, which what I saw. How
huge is the cost of a long here. Most processor handle longs
well today, though many megs of them will hurt the cache.
> Also, if you search the code for '2038' you'll find a remark
> about the year 2038 in DirCacheEntry.smudgeRacilyClean. Last
> I looked at the git sources I think this field in the index is
> treated as a signed time_t so we can't set the high bits and
> extend it out another 60+ years.
That is another time stamp. It is a file time stamp, which we
never store in the Git object database. The index can be revised over time since
it is purely local structure. If it weren't for the need to operate
with C Git in the same repo we could have used a different format,
and nobody would notice. (The first jgit versions used a different
index structure).
time_t is signed, but it is also 64 bit on 64-bit linux so it doesn't overflow in 2038.
$ cev 'printf("sizeof time =%d\n",sizeof(time_t));'
sizeof time =8
> I'd rather just tag the fields with "2038" so we can search for
> them in the future. Like say this:
There should be a comment on the commitTime field too if we choose
that option.
-- robin
^ permalink raw reply
* Re: How do I..?
From: Miklos Vajna @ 2008-12-17 23:49 UTC (permalink / raw)
To: Dylan Martin; +Cc: git
In-Reply-To: <e1a4c7f60812171516h7b7bb1fem35dfc6f30747a740@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Wed, Dec 17, 2008 at 03:16:59PM -0800, Dylan Martin <dmartin@sccd.ctc.edu> wrote:
> Sorry if this is a dumb question. I've poked around the docs and
> tried the google searches I could think of, but I don't even know what
> kind of search terms one would use in trying to answer this.
>
> I'm a sysadmin and I've got a big monolithic git repo of all my
> scripts, documents, etc... It used to be a CVS repo but I converted
> it to git a while ago.
> Before I switched to git, I played around with SVN a bit, and started
> a few tiny SVN repos for various scripts I was working on. So, I know
> have one git repo with %90 of my stuff and a handful of SVN repos.
> I'd like to be able to add the SVN repos as subdirectories inside my
> git repo. I've found lots of pages describing how to convert an SVN
> repo into a _new_ git repo, but I haven't found anything yet about
> importing the contents of an SVN repo as a subdirectory of an
> _existing_ git repo.
I would convert each repo to git, then merge them using subtree merge.
See Documentation/howto/using-merge-subtree.txt.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How do I..?
From: Peter Harris @ 2008-12-17 23:44 UTC (permalink / raw)
To: Dylan Martin; +Cc: git
In-Reply-To: <e1a4c7f60812171516h7b7bb1fem35dfc6f30747a740@mail.gmail.com>
On Wed, Dec 17, 2008 at 6:16 PM, Dylan Martin wrote:
> Before I switched to git, I played around with SVN a bit, and started
> a few tiny SVN repos for various scripts I was working on. So, I know
> have one git repo with %90 of my stuff and a handful of SVN repos.
> I'd like to be able to add the SVN repos as subdirectories inside my
> git repo. I've found lots of pages describing how to convert an SVN
> repo into a _new_ git repo, but I haven't found anything yet about
> importing the contents of an SVN repo as a subdirectory of an
> _existing_ git repo.
You could convert each SVN repo into its own temporary git repo, then
use the subtree merge strategy to combine the git trees:
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Peter Harris
^ permalink raw reply
* rsync deprecated?
From: Markus Heidelberg @ 2008-12-17 23:41 UTC (permalink / raw)
To: git
Hi,
in the "Merging external work" section of the gitcore-tutorial it is
stated that the rsync transport is deprecated. The description was added
in commit 914328a (Update tutorial., 2005-08-30) together with the
"deprecated" note. Having never heard/read this before and since this
commit is quite old, I wonder if it is still the case or there was a
solution for this problem.
Markus
^ permalink raw reply
* Git - index-pack missing
From: Michael Boutros @ 2008-12-17 23:40 UTC (permalink / raw)
To: git
Greetings all,
First of all, thanks for taking the time to read this and help out.
The problem:
I'm trying to clone a repository for the first time on a hosting
account that just got setup with Git. However, the problem is that for
some reason there is no git-index-pack. I cannot find any reason that
that one particular command would not be installed, but for some
reason that seems to be the case.
Has anyone ever heard of anything like this? Is my only option to
completely scrap Git and try again?
Thanks,
Michael Boutros
^ permalink raw reply
* How do I..?
From: Dylan Martin @ 2008-12-17 23:16 UTC (permalink / raw)
To: git
Sorry if this is a dumb question. I've poked around the docs and
tried the google searches I could think of, but I don't even know what
kind of search terms one would use in trying to answer this.
I'm a sysadmin and I've got a big monolithic git repo of all my
scripts, documents, etc... It used to be a CVS repo but I converted
it to git a while ago.
Before I switched to git, I played around with SVN a bit, and started
a few tiny SVN repos for various scripts I was working on. So, I know
have one git repo with %90 of my stuff and a handful of SVN repos.
I'd like to be able to add the SVN repos as subdirectories inside my
git repo. I've found lots of pages describing how to convert an SVN
repo into a _new_ git repo, but I haven't found anything yet about
importing the contents of an SVN repo as a subdirectory of an
_existing_ git repo.
-Thanks!
Dylan
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-17 22:59 UTC (permalink / raw)
To: Johan Herland, git; +Cc: Johannes Sixt
In-Reply-To: <200812170933.04080.johan@herland.net>
> From: Johan Herland <johan@herland.net>
>
> On Wednesday 17 December 2008, Gili Pearl wrote:
> > ----- Original Message ----
> >
> > > From: Johannes Sixt
> > > Gili Pearl schrieb:
> > > > Here is one problem I saw when trying to work in the three-level
> > > > model. At some point, I had the following setup:
> > > >
> > > > top-level : A----B----C----D
> > > > \
> > > > \
> > > > mid-level1: K----L----M
> > > > \
> > > > \
> > > > low-level1: X----Y
> > > >
> > > > The maintainer of mid-level1 has decided that commits K L M are ready
> > > > to be merged into the top-level repo. So he rebased on top-level
> > > > before asking 'please pull', but after that the low-level was not
> > > > able to rebase on the mid-level any more.
> > >
> > > In this model, the mid-level1 maintainer should *not* rebase against
> > > top-level. Rather, he should ask the top-level maintainer to *merge*
> > > K-L-M.
> >
> > But what if K-L-M conflict with C-D? The one who should take care about
> > it is the mid-level1 maintainer (or possibly one of the low-level1
> > maintainers).
>
> If there is a merge conflict, mid-level1 maintainer will typically merge D
> and M into a new merge commit N:
>
> top-level : A----B----C----D
> \ \
> \ \
> mid-level1: K----L----M----N
>
There's one thing that still bothers me and I'd like to understand.
What if someone looks both on top-level repo and mid-level1 repo, and he
want to diff some local commit X against commit D. I didn't try it, but I
wonder how git knows against which D to compare? On the top-level D means
A-B-C-D while on the mid-level1 C means A-K-L-M-B-C-D (that is what git-log
on mid-level shows). I'm probably missing something here... commit id
cannot represent two different histories, right?
> ...and then ask top-level maintainer to merge N (which should have no
> conflicts by now). The merge can also be done by low-level1 developer.
>
How can it be done by low-level1? you mean by bypassing mid-level and merging
top-level directly?
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Junio C Hamano @ 2008-12-17 22:59 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0812171448o3db6f4c1oc24e39f9a68ed1d3@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> On Wed, Dec 17, 2008 at 3:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> (1) if you want to get rid of garbage changes in your work tree, you
>> would want "git checkout $that_path";
>>
>> (2) if you want to temporarily stash away further changes in your work
>> tree, because you would want to first test what is staged, commit it,
>> and then later continue to refine the changes stashed away thusly,
>> you would want "git stash --keep-index".
> ...
> Unfortunately I couldn't figure out how to do this. The solution I
> came up with was to go ahead and `git commit` the staged changes and
> then `git checkout PATH` the just committed file to overwrite the
> local edits with the version of the file I wanted.
How about omitting the "git commit" and do "git checkout PATH" after you
are done with the staging? IOW, (1) above.
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Tim Visher @ 2008-12-17 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6yelf2m.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 17, 2008 at 3:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The last part of the sentence after "because" does not parse for me at
> all...
Sorry for the double/triple/quadruple negatives I threw in there.
Makes the statement incredibly unclear.
> , but I think you are after one of the following:
>
> (1) if you want to get rid of garbage changes in your work tree, you
> would want "git checkout $that_path";
>
> (2) if you want to temporarily stash away further changes in your work
> tree, because you would want to first test what is staged, commit it,
> and then later continue to refine the changes stashed away thusly,
> you would want "git stash --keep-index".
>
>
If I could attempt to make my situation a little clearer.
I had two very similar files (I know, I know, DRY, blah blah. :\ It's
not my source tree to begin with... bleh) and I wanted to duplicate a
bunch of simple edits (adding white space, comments, etc.) from one of
them to the other without having to manually compare them.
Then, a light bulb went off in my head and I thought to myself that it
would make a ton of sense to use `git add -i` to add only the changes
that I wanted to the files and leave the stuff I wanted to be
different between the two of them out. I `cp`ed the edited file over
the other file and then fired up `git add -i` and proceeded to stage
all of the edits that I wanted. This left me with a staged version of
the file that was exactly what I wanted and a locally modified file
with contents that I didn't want. However, the changes were still
untested.
What I wanted to do was basically get rid of the unstaged edits on
this file but keep the staged ones. Without committing.
Unfortunately I couldn't figure out how to do this. The solution I
came up with was to go ahead and `git commit` the staged changes and
then `git checkout PATH` the just committed file to overwrite the
local edits with the version of the file I wanted.
I want to know if it was possible to accomplish this without the commit stage.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [EGIT PATCH] Committer, author and tagger time should not be parsed as 32 bit signed int
From: Shawn O. Pearce @ 2008-12-17 22:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229553172-2038-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> If not dates past 2038 will be parsed the wrong way when
> parsed into a RevCommit or RevTag object.
Uhm, sure.
But there's also the commitTime field in RevCommit, its used to
sort commits during walking. In 2038 that will also overflow.
Also, if you search the code for '2038' you'll find a remark
about the year 2038 in DirCacheEntry.smudgeRacilyClean. Last
I looked at the git sources I think this field in the index is
treated as a signed time_t so we can't set the high bits and
extend it out another 60+ years.
Honestly, I'm not sure this patch is worth the code duplication
without fixing our other two known 2038 problem spots... and
I really don't want to make RevCommit.commitTime into a long,
as that will bloat out the object allocations and slow down the
comparsion on 32 bit JVMs. Right now at the end of 2008 the memory
isn't as readily available and there's still a lot of 32 bit JVMs.
Another 10 years we'll probably be looking at 256 bit wide registers
being very common, and 1 PB of core memory, and extending these
fields out to a long will be trivial. And we'll still have 20
years to make the transition.
I'd rather just tag the fields with "2038" so we can search for
them in the future. Like say this:
--8<--
Mark the other two locations that break in the year 2038
When the 32 bit timestamp rolls over in 2038 these spots in JGit
will break, unless we upgrade them to use a 64 bit long before then.
For now its too time and memory intensive to use a full long here,
but in another 10 years we should have enough computing power that
this is a moot point and we can upgrade the code paths marked with
by 'git grep 2038'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/revwalk/RevCommit.java | 2 ++
.../src/org/spearce/jgit/util/RawParseUtils.java | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
index 9d30018..bcfd8c4 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
@@ -129,6 +129,8 @@ else if (nParents == 1) {
ptr = RawParseUtils.committer(raw, ptr);
if (ptr > 0) {
ptr = RawParseUtils.nextLF(raw, ptr, '>');
+
+ // In 2038 commitTime will overflow unless it is changed to long.
commitTime = RawParseUtils.parseBase10(raw, ptr, null);
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index 55a3001..c2d591b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -414,6 +414,8 @@ public static PersonIdent parsePersonIdent(final byte[] raw, final int nameB) {
final String email = decode(cs, raw, emailB, emailE - 1);
final MutableInteger ptrout = new MutableInteger();
+
+ // In 2038 "when" will overflow. Switch to a long before then.
final int when = parseBase10(raw, emailE + 1, ptrout);
final int tz = parseTimeZoneOffset(raw, ptrout.value);
--
1.6.1.rc3.302.gb14d9
--
Shawn.
^ permalink raw reply related
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