finding the right remote branch for a commit

finding the right remote branch for a commit

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

Dear list,

I am trying to figure out a way to store ~/.etc in git. With SVN,
I would have a .etc repository for each machine, which would use
svn:externals to reference locations of the various subdirectories,
which SVN would then pull and assemble. Thus, my ~/.etc might be

  ~/.etc
  ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]
  ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]
  ...

With git, I am now considering using remote branches for this kind
of stuff. So I'll have a repository for my ssh config and
a repository for my vim config, and so on.

The idea then is to create another repository for each machine and
to register the remote tracking branches there in much the same way
that I used svn:externals previously (and with the added benefit
that I don't have to stay within subdirectories).

Thus, the vim repository might look like this:

  .etc/
  |-- vim/
  |   `-- rc.vim
  `-- .vimrc -> .etc/vim/rc.vim

and the ssh configuration might be

  .etc/
  |-- ssh/
  |   |-- config
  |   `-- authorized_keys
  `-- .ssh -> .etc/ssh/

My theory is that merging all those remotely tracked branches into
a local repo populates my home directory, and bringing it up to the
latest version is as simple as:

  git remote update
  git branch -r | xargs git merge   # any way to just merge all remote branches?

So far so good, this seems to work just fine.

Right now I am trying to figure out how to push updates back to the
central store so that other machines who "subscribe" to a given
branch can receive the updates.

For instance, I may have made a change to ~/.vimrc and to
~/.ssh/config and committed each to the machine-local repository.
What I need now is a way to tell me

  (a) which commits are local and have not been merged from a remote
      tracking branch. If I actually want to keep commits local,
      e.g. because of changes only applicable to this one machine,
      I can move them to a local branch and rebase that whenever the
      remotes change.

  (b) which commits should be pushed where. This is a bit of
      a strange one it may seem, but in my case, remote branches are
      orthogonal and never touch the same file. Thus, each file
      belongs to one remote branch. How can I determine which one?

      Or even better, how could I push all my local commits to the
      respective remotes?

Thanks for any comments, and sorry to be cluttering the list with my
newbie stuff...

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"moderation is a fatal thing. enough is as bad as a meal. more than
 enough is as good as a feast."
                                                        -- oscar wilde

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: finding the right remote branch for a commit

[Johannes Schindelin]

Hi,

On Tue, 10 Jul 2007, martin f krafft wrote:

> I am trying to figure out a way to store ~/.etc in git. With SVN,
> I would have a .etc repository for each machine, which would use
> svn:externals to reference locations of the various subdirectories,
> which SVN would then pull and assemble. Thus, my ~/.etc might be
> 
>   ~/.etc
>   ~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]
>   ~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]
>   ...
>
> [...] 
> 
> Thus, the vim repository might look like this:
> 
>   .etc/
>   |-- vim/
>   |   `-- rc.vim
>   `-- .vimrc -> .etc/vim/rc.vim
> 
> and the ssh configuration might be
> 
>   .etc/
>   |-- ssh/
>   |   |-- config
>   |   `-- authorized_keys
>   `-- .ssh -> .etc/ssh/

Okay, after discussing this for a bit on IRC, here is what I would do (I 
already said this on IRC, but the mailing list is really the better medium 
for this):

I would actually rename .etc/ into gits/, because it is not a directory 
containing settings, but a directory containing repositories.

Then I would create bare repositories gits/vim.git/, gits/ssh.git/, 
gits/mutt.git/, etc. but as soon as I created them, I would make them 
"unbare", i.e. "git config core.bare false".

Everytime I would work on, say, .vimrc, I would say 
"--git-dir=$HOME/gits/vim.git", or maybe even make an alias in 
$HOME/.gitconfig, which spares me that:

$ git config --global vim '!git --git-dir=$HOME/gits/vim.git'

Then I could see the status with

$ git vim status

Come to think of it, this is maybe what I would have done, but it appears 
to me that this is the _ideal_ use case for worktree:

In $HOME/gits:

$ mkdir vim.git && cd vim.git
$ git --work-tree=$HOME init
$ cat >> info/exclude < EOF
*
!/.vimrc
EOF

Then you could do all Git operations like push, fetch, pull, log in 
$HOME/gits/vim.git, and all editing in $HOME.

At least that is the theory.

In practice, and I consider these all bugs, it does not work:

- you have to say

  $ git --work-tree=$HOME --bare init

  which is a bit counterintuitive.  After all, it is _not_ a bare 
  repository.  The whole purpose of worktree, as far as I understand, is 
  to have a _detached_ repository, which would otherwise be called bare.

- $ git status

  does not do what you would expect: it fails, telling you that it needs a 
  work tree, of all things. You can say (tongue-in-cheek)

  $ (export GIT_DIR="$(pwd)" && cd "$(git config core.worktree)" &&
     git status)

  So, git knows about the location of the working tree, but just ignores 
  that.

- In the case that you forget to set GIT_DIR, you better not have any 
  .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that 
  instead!  Even if you are _inside_ a detached git directory!

  So you better not try some games like this in a subdirectory of your 
  local git.git repository.  It is a fine way to get completely confused.  
  And certainly do _not_ do something like "git reset --hard <branch>" 
  there.

- Of course, it would be nice if something like that worked:

  $ cd $HOME/gits/vim.git
  $ git add $HOME/.vimrc

  But it does not work, because it wants to _be_ in the work tree.  Of 
  course, you have to specify the GIT_DIR again, because the working tree 
  does not know about the location of the repository, but vice versa.

Those are serious bugs.  Matthias, any idea how to fix them?

Ciao,
Dscho

Re: finding the right remote branch for a commit

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 3188 bytes --]

also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.07.11.2326 +0200]:
> Okay, after discussing this for a bit on IRC, here is what I would
> do (I already said this on IRC, but the mailing list is really the
> better medium for this):

I agree. However, I find IRC to have its merits. For instance, all
of our discussion yesterday would have taken days over the list, but
on IRC I was able to interject when I did not understand something
or you could stop me when I was going down a garden path.

Of course, IRC isn't archived in the sense that lists are, which is
why I make an effort to send updates to the list, such as I did to
another thread yesterday: http://marc.info/?l=git&m=118418250002028&w=2

> I would actually rename .etc/ into gits/, because it is not
> a directory containing settings, but a directory containing
> repositories.

Yes and no. I already use ~/.etc/ to store my settings and symlink
into it, but I do like your idea too, actually. I have yet to go
and try it, and I shall report back then.

> Everytime I would work on, say, .vimrc, I would say
> "--git-dir=$HOME/gits/vim.git", or maybe even make an alias in
> $HOME/.gitconfig, which spares me that:

I wish there were a way to determine which repository a file belongs
to and then to automatically select the right repository. I guess
one can script that by iterating all repos and using git-ls-files,
possibly caching the result.

Anyway, I tried your approach and failed:

  $ mkdir repo
  $ GIT_DIR=repo git init
  $ GIT_DIR=repo git config core.bare false
  $ echo 1 >a; GIT_DIR=repo git add a; GIT_DIR=repo git commit -m.
  fatal: add must be run in a work tree
  nothing to commit (use "git add file1 file2" to include for commit)

I am probably doing something wrong, but what?

> Come to think of it, this is maybe what I would have done, but it appears 
> to me that this is the _ideal_ use case for worktree:

Yes, it does. I am downloading the source now and intend to work
with the HEAD (is that the right term for what I used to call trunk
when I was doing SVN?) from now on (instead of the Debian package).

> - you have to say
> 
>   $ git --work-tree=$HOME --bare init
> 
>   which is a bit counterintuitive.  After all, it is _not_ a bare 
>   repository.  The whole purpose of worktree, as far as I understand, is 
>   to have a _detached_ repository, which would otherwise be called bare.

I said

  GIT_DIR=repo git --work-tree `pwd` init

and that seems to do everything it should, it sets core.worktree to
. and core.bare to false.

> Those are serious bugs.  Matthias, any idea how to fix them?

That would be splendid. I am operating off HEAD now, so feel free to
prod me for any testing.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"a scientist once wrote that all truth passes through three stages:
 first it is ridiculed, then violently opposed and eventually,
 accepted as self-evident."
                                                       -- schopenhauer

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: finding the right remote branch for a commit

[Jakub Narebski]

martin f krafft wrote:

> Yes, it does. I am downloading the source now and intend to work
> with the HEAD (is that the right term for what I used to call trunk
> when I was doing SVN?) from now on (instead of the Debian package).

HEAD means _current_ branch. You can work off 'master' or 'next' branches,
and if you feel really adventurous even off 'pu' branch.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: finding the right remote branch for a commit

[Matthias Lederhofer]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> In practice, and I consider these all bugs, it does not work:
> 
> - you have to say
> 
>   $ git --work-tree=$HOME --bare init
> 
>   which is a bit counterintuitive.  After all, it is _not_ a bare 
>   repository.  The whole purpose of worktree, as far as I understand, is 
>   to have a _detached_ repository, which would otherwise be called bare.

Use

    $ git --work-tree "$HOME" --git-dir . init

instead.

IMHO the --bare flag did not make much sense before the introduction
of GIT_WORK_TREE and doesn't after, at least not with the meaning it
has: why should 'git --bare' mean to use the repository from cwd?
Ok, git --bare implies that you cannot use a working tree because
you're at the top of the git repository directory which may not be
used as working tree.

Now bare only means that some protection mechanisms are disabled and
some default values change (i.e. overwrite HEAD, enable/disable
reflogs by default).  So maybe the name bare itself is a bit
counterintuitive now.

> - $ git status
> 
>   does not do what you would expect: it fails, telling you that it needs a 
>   work tree, of all things. You can say (tongue-in-cheek)
> 
>   $ (export GIT_DIR="$(pwd)" && cd "$(git config core.worktree)" &&
>      git status)
> 
>   So, git knows about the location of the working tree, but just ignores 
>   that.
> 
> - In the case that you forget to set GIT_DIR, you better not have any 
>   .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that 
>   instead!  Even if you are _inside_ a detached git directory!
> 
>   So you better not try some games like this in a subdirectory of your 
>   local git.git repository.  It is a fine way to get completely confused.  
>   And certainly do _not_ do something like "git reset --hard <branch>" 
>   there.
>
> - Of course, it would be nice if something like that worked:
> 
>   $ cd $HOME/gits/vim.git
>   $ git add $HOME/.vimrc
> 
>   But it does not work, because it wants to _be_ in the work tree.  Of 
>   course, you have to specify the GIT_DIR again, because the working tree 
>   does not know about the location of the repository, but vice versa.

Up to now you are supposed to be in the working tree all the time when
using it.  Therefore I'd call these feature requests rather than bugs :)

For git status it should be quite easy to add a special case to change
to the top of the working tree as long as no paths are used as
parameters.

When paths are used (either with git status or git add) you'd have to
translate the specified path to a path relative to the working tree.
This should be possible with chdir, getcwd and prefixcmp.  If this
gets implemented for git status/git add it should probably get
implemented for all commands for which it makes sense.  I think this
would be nice to have but I'm not sure how complicated this is to
implement.

Re: finding the right remote branch for a commit

[Johannes Schindelin]

Hi,

you left enough hints to convince me that you will not fix the bugs.  
So I will bite the bullet, and find some time this week to fix the issues.

Junio, I'd really appreciated if you considered waiting with 1.5.3 (maybe 
do an -rc2?) before these bugs are squashed.

On Mon, 16 Jul 2007, Matthias Lederhofer wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > In practice, and I consider these all bugs, it does not work:
> > 
> > - you have to say
> > 
> >   $ git --work-tree=$HOME --bare init
> > 
> >   which is a bit counterintuitive.  After all, it is _not_ a bare 
> >   repository.  The whole purpose of worktree, as far as I understand, is 
> >   to have a _detached_ repository, which would otherwise be called bare.
> 
> Use
> 
>     $ git --work-tree "$HOME" --git-dir . init
> 
> instead.

Why _should_ that be necessary at all?  I _already_ told git that the 
working tree is somewhere else.  It makes _no sense at all_ to treat the 
cwd as anything else than the GIT_DIR, when --work-tree but no --git-dir 
were specified.

> IMHO the --bare flag did not make much sense before the introduction
> of GIT_WORK_TREE and doesn't after, at least not with the meaning it
> has: why should 'git --bare' mean to use the repository from cwd?

To the contrary, it makes tons of sense.  If you want to initialise a bare 
repository, what _more_ natural way than to say "git init --bare"?  And 
what _more_ natural place to pick for GIT_DIR than the cwd, when you did 
not specify --git-dir?

> > [descriptions of bugs, that have been largely ignored]
>
> Up to now you are supposed to be in the working tree all the time when 
> using it.  Therefore I'd call these feature requests rather than bugs :)

Feature requests? WTF? What reason is there for the _requirement_ to 
specify a working tree, when git does not make use of it?  Hmm?

Ciao,
Dscho

Re: finding the right remote branch for a commit

[Matthias Lederhofer]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 16 Jul 2007, Matthias Lederhofer wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Use
> > 
> >     $ git --work-tree "$HOME" --git-dir . init
> > 
> > instead.
> 
> Why _should_ that be necessary at all?  I _already_ told git that the 
> working tree is somewhere else.  It makes _no sense at all_ to treat the 
> cwd as anything else than the GIT_DIR, when --work-tree but no --git-dir 
> were specified.
>
> > IMHO the --bare flag did not make much sense before the introduction
> > of GIT_WORK_TREE and doesn't after, at least not with the meaning it
> > has: why should 'git --bare' mean to use the repository from cwd?
> 
> To the contrary, it makes tons of sense.  If you want to initialise a bare 
> repository, what _more_ natural way than to say "git init --bare"?  And 
> what _more_ natural place to pick for GIT_DIR than the cwd, when you did 
> not specify --git-dir?

Ah, for git init it makes sense to have the --bare flag and also to
use the cwd as GIT_DIR when GIT_WORK_TREE is specified.

> > > [descriptions of bugs, that have been largely ignored]

The last paragraphs were for the second and fourth one (git status/add
from outside the working tree): it should be possible to fix this but
it might be a bit complicated.  And if it is done for a few commands
probably all commands should support this.

For the third one (git picks up another git repository even if it is
inside a 'detached working tree') I have no idea how to fix this.  The
working tree cannot be recognized in any way.  Maybe you can/should
use a symlink to the real repository named .git in this case?  But
this only works as long as you checkout only one repository in the
directory.

> > Up to now you are supposed to be in the working tree all the time when 
> > using it.  Therefore I'd call these feature requests rather than bugs :)
> 
> Feature requests? WTF? What reason is there for the _requirement_ to 
> specify a working tree, when git does not make use of it?  Hmm?

Sorry, I don't understand what you mean yet.  Where does git require
you to specify a working tree?