On Mon, Dec 24, 2012 at 8:31 AM, Woody Wu wrote:
> But thanks anyway, I see you guys's discussions and it's a little hard
> to understand to me at the moment. Currently, I still have to use gitk
> with narrowed outputs.
Each commit refers to it's parent. If you take a branch, and keep
following t
On Mon, Dec 24, 2012 at 1:19 PM, Jeff King wrote:
> On Mon, Dec 24, 2012 at 12:28:45PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > You want to know "what commit was I at when I typed `git branch
>> > mybranch`"? The problem is git doesn't record this information and
>> > doesn't have the slightest
On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>> wrote:
Maybe we should store this information. reflog is a perfect place for
this, I think. If this information is reliably available, git reba
e...@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> diff --git a/git-p4.py b/git-p4.py
> index 551aec9..ec060b4 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> import tempfile, getopt, os.path, time, platform
> import r
Hi,
we are using git since may and all is working fine for all of us (almost
20 people) on our workstations. However, when we clone our repositories
to the cluster, only and only there
we are having many problems similiar to this post:
http://thread.gmane.org/gmane.comp.file-systems.lustre.u
Eric Chamberland writes:
> #1) However, how can we *test* the filesystem (lustre) compatibility with
> git? (Is there a unit test we can run?)
Have you considered running git's testsuite?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44
On 12-12-24 09:08 AM, Eric Chamberland wrote:
> Hi,
Hi,
> Doing a "git clone" always work fine, but when we "git pull" or "git gc"
> or "git fsck", often (1/5) the local repository get corrupted.
Have you tried adding a "-q" to the git command line to quiet down git's
"feedback" messages?
I dis
Pete Wyckoff :
> e...@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> > diff --git a/git-p4.py b/git-p4.py
> > index 551aec9..ec060b4 100755
> > --- a/git-p4.py
> > +++ b/git-p4.py
> > @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> > import tempfile, getopt, os.pat
On Mon, Dec 24, 2012 at 06:16:05PM +0700, Nguyen Thai Ngoc Duy wrote:
> > The reason that git does not bother storing "where did I start this
> > branch" is that it is usually not useful. The right question is usually
> > "what is the merge base". There are exceptions, of course (e.g., if you
> >
On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu wrote:
> On Sun, Dec 23, 2012 at 11:09:58PM -0500, Seth Robertson wrote:
>>
>> In message <20121224035825.GA17203@zuhnb712>, Woody Wu writes:
>>
>> How can I find out what's the staring reference point (a commit number
>> or tag name) of a locally
Nguyen Thai Ngoc Duy writes:
> On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano wrote:
>> Nguyen Thai Ngoc Duy writes:
>>
>>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>>> wrote:
> Maybe we should store this information. reflog is a perfect place for
> this, I think. If this info
"Eric S. Raymond" writes:
> Pete Wyckoff :
>> e...@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
>> ...
>> Many of your changes have these three problems; I just picked on
>> my favorite one.
>
> Should I resubmit, or do you intend to fix these while merging?
I'd appreciate a re-roll, perh
Junio C Hamano :
> > Should I resubmit, or do you intend to fix these while merging?
>
> I'd appreciate a re-roll, perhaps in a few days after the dust
> settles.
You'll get it.
It will take a little longer than it otherwise might have because I'm
in the middle of straightening out the mess arou
I've been running testsuite on a few platforms that are unfamiliar
to me, and was bitten by BSD implementation of tar that do not grok
the extended pax headers. I've already fixed one in t9502 [*1*]
where we produce a tarball with "git archive" and then try to
validate it with the platform impleme
On Tue, Dec 25, 2012 at 2:10 AM, Junio C Hamano wrote:
>> I looked briefly at reflog before writing my previous mail and noticed
>> that when I create a new branch (usually using "git checkout -b branch
>> ref") it does not record the base commit.
>
> Hmph. Perhaps you are referring to something
Some platforms (e.g. NetBSD 6.3) seem to configure their CVS to
allow "cvs init" in an existing directory only to members of
"cvsadmin".
Instead of preparing an empty directory and then running "cvs init"
on it, let's run "cvs init" and let it create the necessary
directory.
Signed-off-by: Junio
we are using git since may and all is working fine for all of us
(almost 20 people) on our workstations. However, when we clone our
repositories to the cluster, only and only there
we are having many problems similiar to this post:
What filesystem tests have you run on lustre? I would r
Junio C Hamano writes:
> Some platforms (e.g. NetBSD 6.3) seem to configure their CVS to
s/6.3/6.0/; sorry for the noise.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
18 matches
Mail list logo
