headers
Nicolas Pitre | 1 Feb 2007 01:11

Re: [PATCH] tone down the detached head warning

On Wed, 31 Jan 2007, Jeff King wrote:

> On Wed, Jan 31, 2007 at 02:10:37PM -0500, Nicolas Pitre wrote:
> 
> > This is not meant to frighten people or even to suggest they might be
> > doing something wrong, but rather to notify them of a state change and
> > provide a likely option in the case this state was entered by mistake.
> 
> I like this much better. Though I wonder in Carl's case if we can do
> even better, since the user is checking out a tracking branch. Does it
> really make sense to say "you are not on ANY branch"? Maybe instead:
> 
[...]
> +		case "$detached_remote" in
> +		  "") detach_warn="Note: you are not on ANY branch anymore." ;;
> +		   *) detach_warn="Note: you are on the remote tracking branch '$detached_remote'" ;;
> +		esac

No.  This is misleading.

You are _not_ on the remote tracking branch.  You just happen to have 
checked out a commit that came from a tracking branch, but you are still 
detached from any branch at that point.

Nicolas
Permalink | Reply | 25 comments |
headers
Jakub Narebski | 1 Feb 2007 01:14
Picon
Gravatar

Re: [PATCH] tone down the detached head warning

Carl Worth wrote:

> So it does come around to the fact that I'd like it to be easier for a
> user to get all the configuration setup for a local branch that knows
> which remote-tracking branch its associated with, (and this whether or
> not the remote-tracking branch was configured as part of the original
> clone or not).

There is new (untested and not complete) command git-remote for that.

Although the fact that clone copies all branches and tags (I don't think
there is a way to clone only subset of branches), and that fetch is multi
branch might be deterrent enough (unless one use one branch per repo).
--

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Permalink | Reply | 2 comments |
headers
Josef Weidendorfer | 1 Feb 2007 01:20
Picon
Picon

Re: Difficulties in advertising a new branch to git newbies

On Wednesday 31 January 2007, Carl Worth wrote:
> > It would be nice if:
> >
> > git clone -b ${branch} git://...

Nice indeed.

Additionally, it would be nice for clone to directly
checkout tags. Why not an option "--checkout <ref>"
to directly checkout <ref> after cloning?

This goes nicely with the "-b" option
to create a new branch. A "-b <branch>" option alone would
imply "--checkout origin/<branch>". And without "--checkout"
or "-b" option it defaults to "-b master" which gives
exactly the same behavior as now.

This way,

 git clone --checkout v1.0 git://...

would checkout tag v1.0, and use a detached head for it.

> In addition, it would be great to have a command that did the same
> setup within an existing repository.

Why not use "git clone" for this?
Currently, the man page says about the directory it will clone into:

 "Cloning into an existing directory is not allowed."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Feb 2007 01:26
Picon
Picon

[ANNOUNCE] GIT 1.5.0-rc3

It's been a week and a half, and here comes the -rc3

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.0-rc3.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.0-rc3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.0-rc3.tar.{gz,bz2}		(preformatted docs)
  testing/git-*-1.5.0-rc3-1.$arch.rpm		(RPM)

Hopefully this will be the last -rc before the final 1.5.0.

This contains the "git user's manual" by J. Bruce Fields.  While
it still has its own "To Do" section, it has already been in a
very good shape for some time, giving information with coherence
and guiding a new user in a carefully chosen order of topics
into much more pleasant git experience than before.

----------------------------------------------------------------

Changes since v1.5.0-rc2 are as follows:

Alex Riesen (5):
  Insert ACTIVESTATE_STRING in Git.pm
  Force Activestate Perl to tie git command pipe handle to a handle class
  Cleanup uninitialized value in chomp
  Allow default core.logallrefupdates to be overridden with template's config
  Fix git-update-index to work with relative pathnames.

Alexandre Julliard (1):
  vc-git.el: Take into account the destination name in vc-checkout.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Matt Mackall | 1 Feb 2007 01:34
Favicon

Re: newbie questions about git design and features (some wrt hg)

On Thu, Feb 01, 2007 at 12:58:42AM +0100, Jakub Narebski wrote:
> Matt Mackall wrote:
> > On Wed, Jan 31, 2007 at 11:56:01AM +0100, Jakub Narebski wrote:
> >> Theodore Tso wrote:
> >> 
> >>> On Tue, Jan 30, 2007 at 11:55:48AM -0500, Shawn O. Pearce wrote:
> >>>> I think hg modifies files as it goes, which could cause some issues
> >>>> when a writer is aborted.  I'm sure they have thought about the
> >>>> problem and tried to make it safe, but there isn't anything safer
> >>>> than just leaving the damn thing alone.  :)
> >>> 
> >>> To be fair hg modifies files using O_APPEND only.  That isn't quite
> >>> as safe as "only creating new files", but it is relatively safe.
> >> 
> >>>From (libc.info):
> >> 
> >>  -- Macro: int O_APPEND
> [...] 
> >> I don't quote understand how that would help hg (Mercurial) to have
> >> operations like commit, pull/fetch or push atomic, i.e. all or
> >> nothing. 
> > 
> > That's because it's unrelated.
> [...]
> > Mercurial has write-side locks so there can only ever be one writer at
> > a time. There are no locks needed on the read side, so there can be
> > any number of readers, even while commits are happening.
> > 
> >> What happens if operation is interrupted (e.g. lost connection to
> >> network during fetch)?
(Continue reading)

Permalink | Reply | 70 comments |
headers
Jakub Narebski | 1 Feb 2007 01:57
Picon
Gravatar

Re: newbie questions about git design and features (some wrt hg)

Matt Mackall wrote:
> On Thu, Feb 01, 2007 at 12:58:42AM +0100, Jakub Narebski wrote:

>> Sidenote 1: it looks like git is optimized for speed of merge and checkout
>> (branch switching, or going to given point in history for bisect), and
>> probably accidentally for multi-branch repos, while Mercurial is optimized
>> for speed of commit and patch.
> 
> I think all of these things are comparable.

Hierarchical tree objects in git optimize for speed of merge and checkout
IMVHO, as you need only to check out one hash to know if you have to
descend into subdirectory, or if given subdirectory haven't changed.
Flat manifest file in Mercurial (and also "filename buckets") makes
commits faster, I think.

>> Sidenote 2: Mercurial repository structure might make it use "file-ids"
>> (perhaps implicitely), with all the disadvantages (different renames
>> on different branches) of those.
> 
> Nope.

How it is so, if the blobs (file contents) are stored filename hashed?
IIRC hg has some scheme to deal with renames, but it is file-id (file
identity) based AFAIK.

--

-- 
Jakub Narebski
Poland
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jakub Narebski | 1 Feb 2007 03:33
Picon
Gravatar

Re: two-way sync; from firewalled host

Yakov Lerner wrote:

> I have two hosts, host C which is firewalled (no sshd),
> and host S which has sshd and is not firewalled. Both have
> clone of the same repo, modified locally and differently on both hosts.
> 
> I need to two-way sync them by running commands on C (the firewalled one).

You can on host C pull from host S, and on host C push to host S.
--

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Permalink | Reply | 1 comment |
headers
Mark Levedahl | 1 Feb 2007 02:41
Picon

Re: [PATCH] Make gitk work reasonably well on Cygwin.

The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window 
sashes to get a useable layout. However, if ~/.gitk existed, this was 
not possible at all.

The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous 
bugs in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.

Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
    pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
    Again, this is necessary to get around a layout problem on Cygwin.

Also, responding to other comments on this thread:

1) Regarding the size of the patch. I tried many different approaches to 
getting the layout to work on Cgywin as well as Linux, ultimately the 
only approach that worked required changing the very top level structure 
containing the Tk widgets. As the  style used names all widgets using 
their parents, every widget's name is changed. This makes the patch seem 
more complex than it is, many changes  are just changing names. There 
might be a simpler solution, I didn't find it and I can find absolutely 
no indication from googling that anyone else has found a better solution.

2) I have changed the default window size (used only the first time gitk
(Continue reading)

Permalink | Reply | 13 comments |
headers
Jeff King | 1 Feb 2007 04:00
Gravatar

Re: [PATCH] tone down the detached head warning

On Wed, Jan 31, 2007 at 07:11:34PM -0500, Nicolas Pitre wrote:

> No.  This is misleading.
> 
> You are _not_ on the remote tracking branch.  You just happen to have 
> checked out a commit that came from a tracking branch, but you are still 
> detached from any branch at that point.

Sure, but that is a very subtle distinction that I doubt will make sense
to git newbies. Having them check out what they consider to be a branch
(and which is, in fact, a line of development -- just not one that you
have locally marked as a head) and responding with "you are not on ANY
branch" is a little off-putting.

Is there some text we can use that makes more sense in all situations?

I think part of the "scariness" of the message is that git-checkout does
not _usually_ produce output. I wonder if, when switching HEAD, it
usually printed "Now on branch <foo>", and for detached printed some
special variant, it would seem more natural.

-Peff
Permalink | Reply | 24 comments |
headers
Mark Levedahl | 1 Feb 2007 03:09
Picon

Re: [PATCH] Make gitk work reasonably well on Cygwin.

The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window 
sashes to get a useable layout. However, if ~/.gitk existed, this was 
not possible at all.

The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous 
bugs in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.

Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
    pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
    Again, this is necessary to get around a layout problem on Cygwin.

Also, responding to other comments on this thread:

1) Regarding the size of the patch. I tried many different approaches to 
getting the layout to work on Cgywin as well as Linux, ultimately the 
only approach that worked required changing the very top level structure 
containing the Tk widgets. As the  style used names all widgets using 
their parents, every widget's name is changed. This makes the patch seem 
more complex than it is, many changes  are just changing names. There 
might be a simpler solution, I didn't find it and I can find absolutely 
no indication from googling that anyone else has found a better solution.

2) I have changed the default window size (used only the first time gitk
(Continue reading)

Permalink | Reply | 0 comments |

Gmane