Re: git for versioning

[martin f krafft]

also sprach Rustom Mody [EMAIL PROTECTED] [2008.07.30.0851 +0200]:
 But how do I work on the base and have it push (yeah, that's not
 exactly the word) its changes through the (branches for) Albert, Beth
 and Foo?

You push them to a central location and they fetchmerge from there,
or they fetch from your repo and merge.

 I tried to study rebase for this but I guess its not the thing I want.

You could have them rebase too, but I suggest you don't until you
are comfortable with Git.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
if you find a spelling mistake in the above, you get to keep it.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: git for versioning

[martin f krafft]

also sprach Rustom Mody [EMAIL PROTECTED] [2008.07.30.1113 +0200]:
  But how do I work on the base and have it push (yeah, that's not
  exactly the word) its changes through the (branches for) Albert, Beth
  and Foo?
 
  You push them to a central location and they fetchmerge from there,
  or they fetch from your repo and merge.
 
 merge I can understand.
 But why push and fetch? Its all on the local machine.

you need to pull revisions from the other repos.

I strongly suggest you read

  http://git.or.cz/course/svn.html
  http://utsl.gen.nz/talks/git-svn/intro.html (even though git-svn,
  this is still good for learning git)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

(valid) criticisms of Git addressed (was: I am using fsvs and just found svnhome in google...)

[martin f krafft]

also sprach Juliano F. Ravasi [EMAIL PROTECTED] [2008.08.27.0302 +0100]:
 1. Both don't see directories. Just because a directory is empty
 doesn't mean that it doesn't exist. If I delete all files in
 a directory, it doesn't mean that that directory ceased to exist.
 Some programs don't expect this. For example, file all messages
 from your Inbox, and commit. Then you pull from the other machine,
 and your Inbox directory just disappears.

If you emptied your inbox, why keep it around? I expect the tools
I use to recreate empty directories aqs needed.

This is apart from the fact that I prefer to use IMAP for
synchronising mail, since it's a better tool (made) for the task and
can do stuff (like flags) better than a mail-agnostic tool, such as
a content tracker.

 2. Both lack proper ways to store metadata. This is evidenced by
 the need to pollute your directories with .gitignore,
 .gitattributes and .gitmodules (for Git), and .hgignore,
 .hgbranches and .hgtags (for Mercurial). All this information is
 threated and versioned as part of the contents of the repository,
 while it should not. It is the plumbing of the VCS that gets
 exposed and mixed with the user files.

This is a very valid point and I wish Git had a metadata layer. I've
tried to bring up the issue with the developers, but they're not
interested in making Git more generic (it's used to track the linux
kernel sources, if you use it for anything else, you are on your
own).

But keep in min that Git, Mercurial  Co. are first-generation (if
you are willing to place arch into the zeroth generation, and see
Monotone in a league of its own). We are surely going to see new
tools which pick up on these issues in the future.

There is one thing to be said in favour of in-filesystem metadata,
such as .gitattributes — conflicts in those are no different than
conflicts in content files, and all of the standard and advanced
conflict resolution mechanisms (merge drivers, git-rerere, etc.) can
be used for those just as well. Surely, this could be remedied by
exposing the metadata layer as files in the event of conflicts, but
that would be a hack in my world, and likely come with other
problems.

 In the case of Git, .gitattributes is a huge misfeature. The
 attributes stored in it are user-edited, and is not attached to
 the actual files. If you move files around, you suddenly lose your
 attributes until you fix the attributes file.

Agreed.

 4. Git only: lack of real rename/copy support. This affects not
 only vcs-home, but also general SCM use; it is just worse for
 vcs-home. There is a much bigger likelihood of having binary files
 in your home than common source code projects (what Git was
 designed to manage). Images, text documents, spreadsheets,
 presentations, compressed files, etc... For example, you change
 a single character in an ODF document and save. You will see that
 the file is completely different binary-wise, not easy to track.

Git doesn't track the file, it tracks the content. If you make small
changes, it's likely that the two blobs will be compressed to little
more than the size of one in the store. When it comes to keeping the
association (e.g. log messages), Git uses commit history anyway to
figure this out.

 If you also rename before the commit, you just lose the
 connection, and there is nothing you can do about it.

This has not happened to me before, or well, it's not bitten me.

Do you mean something like:

+lapse:~/.tmp/cdt.VLULwrjW|master|% echo foo  testfile
fatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git add testfile
gfatal: No HEAD commit to compare with (yet)
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'add testfile(foo)'
Created initial commit 3ff1892: add testfile(foo)
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% echo bar | testfile  
changes on filesystem:
 testfile |2 +-
+lapse:~/.tmp/cdt.VLULwrjW|master|% git mv testfile someotherfile
cached/staged changes:
 someotherfile |1 +
 testfile  |1 -
+lapse:~/.tmp/cdt.VLULwrjW|master|% git commit -m'moved the file to 
someotherfile(bar)'
Created commit 78b242f: moved the file to someotherfile(bar)
 2 files changed, 1 insertions(+), 1 deletions(-)
 create mode 100644 someotherfile
 delete mode 100644 testfile
+lapse:~/.tmp/cdt.VLULwrjW|master|% git log -- someotherfile 
commit 78b242f2d5df1ebe96e25e2dc6c69eb1c135cbb2
Author: martin f. krafft [EMAIL PROTECTED]
Date:   Wed Aug 27 13:55:37 2008 +0100

moved the file to someotherfile(bar)

 5. Git doesn't actually support Unicode filenames (neither does
 Mercurial). Both just store whatever the file name is in the
 filesystem directly into the repository, as just an array of
 bytes. You won't notice this unless you create files with names
 containing characters beyond the ASCII set, and use different
 encodings in different computers. This also causes problems when
 cloning your repositories

Re: (valid) criticisms of Git addressed

[martin f krafft]

also sprach Juliano F. Ravasi [EMAIL PROTECTED] [2008.08.27.1958 +0100]:
  If you emptied your inbox, why keep it around? I expect the tools
  I use to recreate empty directories aqs needed.
 
 Yes, but some programs don't expect their directories to disappear.

Then I think those programmes are buggy. Empty directories have no
meaning, I think.

 See? Just a single-pixel change of an image, together with
 a rename from draft.png to final.png broke the history, because
 Git doesn't record this information.

Sure, it's ugly, but if you edit and rename in two separate commits,
it works fine. So it is possible and should be fixed.

In any case, I usually put renames into their own commits, so that's
why I have not been bitten by this yet.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
never trust an operating system
for which you do not have the source.
   -- source unknown
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: OT: tips for directory structure for recurring LaTeX projects

[martin f krafft]

also sprach Paul Menzel [EMAIL PROTECTED] [2008.09.04.1220 +0100]:
 I do write letters and protocols using LaTeX with KOMA-Script
 (texdoc scrguien). Now I want to start using a VCS.

I use something similar to you, but I have all my letter-writing
classes and files in $TEXMFHOME, where they are in VCS:

  http://git.madduck.net/v/etc/texmf.git

and I use vimplate to create new letters.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a: no.
q: should i include quotations after my reply?
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Python script for automatic synchronization based on inotify

[martin f krafft]

also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.20.1235 +0100]:
 oh, one more thing.
 you can query the current branch in a pure-python way, by reading .git/HEAD

No, please do not use this. Use

  git symbolic-ref -q HEAD || git name-rev --name-only HEAD

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
sex an und für sich ist reine selbstbefriedigung.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Python script for automatic synchronization based on inotify

[martin f krafft]

also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.23.0933 +0100]:
 well, the idea behind doing it in pure-python is removing the
 overhead of spawning extra processes, do you have an argument why
 reading the branchname of the current HEAD in a few lines of
 python is bad?

.git/* is not a public API. It's considered internal.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
america may be unique in being a country which has leapt
 from barbarism to decadence without touching civilization.
-- john o'hara
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Python script for automatic synchronization based on inotify

[martin f krafft]

also sprach Felix Kaiser felix.kai...@fxkr.net [2011.03.23.1250 +0100]:
  .git/* is not a public API. It's considered internal.
 
 
 Not its not.
 
 Its even documented[1]: ... a valid git repository must have the
 HEAD file; some porcelains may use it to guess the designated
 default branch of the repository (usually master).

Ha. This is news to me. Interesting, thanks.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
next the statesmen will invent cheap lies, putting the blame upon the
 nation that is attacked, and every man will be glad of those
 conscience-soothing falsities, and will diligently study them, and
 refuse to examine any refutations of them; and thus he will by and by
 convince himself that the war is just, and will thank god for the
 better sleep he enjoys after this process of grotesque
 self-deception.
 -- mark twain
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: fake git repositories.. how far do you go?

[martin f krafft]

also sprach martin f krafft madd...@madduck.net [2011.04.06.1040 +0200]:
 detached bare would be better.

Actually, see
http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html

Sorry,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the surest way to corrupt a youth is to instruct him to hold in
 higher esteem those who think alike than those who think
 differently.
  -- friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

attachments (was: [mr] support for vcsh)

[martin f krafft]

also sprach Richard Hartmann richih.mailingl...@gmail.com [2011.11.29.2255 
+0100]:
 I got a report that there's no attachment to this email. The email i
 sent _does_ have an attachment, the archive does not...

The list does filter certain types of attachment. Part of the reason
is that attachments cannot be changed (like pastes…). So instead,
I always suggest that you ought to send gitweb URLs ;)

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
for years, we have thought that a million monkeys typing at a million
typewriters would eventually produce the complete works of shakespeare.
today, thanks to the internet, we know this is not true.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

My vcsh is deprecated

[martin f krafft]

Folks,

just so you know: I have deprecated my vcsh script a long time ago,
and now it's official:

  
http://git.madduck.net/v/etc/zsh.git/commitdiff/4e5f7ffb64e3e06024312c9d8595c4504dd1

Since RichiH's vcsh is fully functional and compatible, please
migrate to his:

  https://github.com/RichiH/vcsh

The can only be one, and from now on, vcsh is RichiH's script.

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
everyone has a little secret he keeps,
 i like the fires when the city sleeps.
  -- mc 900 ft jesus
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: trying out vcsh

[martin f krafft]

also sprach Brian May br...@microcomaustralia.com.au [2012.02.06.0116 +0100]:
 Just recently I heard of this vcsh thing, just some of my initial
 thoughts.

Just recently started to clean out my inbox… ;)

 2. I found following the instructions for creating new
 repositories insufficient (section 4.1.4); I also had to add the
 following to $HOME/.config/vcsh/repo.d/foo.git/config:
 
 [branch master]
 remote = origin
 merge = refs/heads/master
 
 otherwise mr pull won't work. Is there an easier way to make
 this change, e.g. using git command line?

vcsh run foo git config branch.master.remote origin
…

 3. If I accidentally add a repository I didn't want, is there an
 easy way of removing it and the checked out files? Maybe this is
 what vcsh delete is meant to do?

vcsh remove now exists.

 4. What is the recommended practise for $HOME/.gitignore? I found
 this file on one host only, and it is not committed anywhere.
 Should I be adding it to a repository?

I am still working on that. Right now, vcsh write-gitignore writes
a file into ~/.gitignore.d/ for each repo, but that file is only
used by the repo. And while this makes work within a repo nice and
tidy (mostly), it has a couple of drawbacks:

  - git add requires the -f flag
  - no trivial way to reuse the information outside of the repo,
e.g. for a ~/.git repository. Wouldn't it be nice to be able to
say git status in ~ and be told which files are not tracked by
*any* repo?
  - I don't like that ~/.gitignore.d/foo is a config file that
mostly just replicates (cached) what is known to Git. I feel
like this information can be extracted from Git directly. But
I have not figured out how to deal with non-tracked files like
.Xauthority. I would want my 'x' repo to know to ignore the
file. Right now, I could add it to ~/.gitignore/x but I don't
want to use those files as config files.

 5. Suspect this is related to 4; am concerned about the
 possibility that I might accidentally commit the same file to two
 different repositories. For example by running git add on the
 wrong repository. Are there any safe guards to prevent this from
 happening?

Wouldn't be hard to do, again using vcsh which. The requirement to
pass -f to git add is also a bit of a safe-guard. Best practice
might be to add an exclusion to the respective gitignore file before
adding, then the -f won't be needed.

 6. Would it be possible to implement commands that, assuming the file
 is already committed to an active repository, automatically work out
 this repository from the list of files? e.g.
 
 vcsh add .zshenv
 vcsh commit
 
 and/or
 
 vcsh commit .zshenv

This should be possible with a simple wrapper around vcsh which and
vcsh run, e.g.

  vcsh which '^\.zshenv' | cut -d: -f1 | xargs -I '{}' vcsh run '{}' git …

Arguably, this could be made into a vcsh subcommand, e.g.

  vcsh run-by-file '^\.zshenv' git …

 7. I can see why it is done this way, but not entirely comfortable
 with having duplicate information about repositories (e.g. the
 upstream repository) both in $HOME/.config/mr/available.d and
 $HOME/.config/vcsh/repo.d . For example, if you want to change to
 upstream repository, it becomes clumsy to do so; I think every host
 would have to be updated manually (at least the repo.d directories).
 Similarly, when a repository is activated, there are two places that
 have to be changed to reflect this that could become inconsistent with
 each other. Still thinking about this issue.

I cannot think of a smart way to reuse these data. The way I think
you are supposed to approach this is by making the change in
$HOME/.config/mr/available.d and add a pre-hook to the update
command to fire off the appropriate vcsh run … git config … commands
prior to running the update.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
with sufficient thrust, pigs fly just fine. however, this is not
 necessarily a good idea. it is hard to be sure where they are going
 to land, and it could be dangerous sitting under them as they fly
 overhead.
   -- rfc 1925
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: cdgit: cd relative to git workdir root

[martin f krafft]

also sprach Thomas Koch tho...@koch.ro [2013.09.16.2101 +0200]:
 shell alias cdgit = cd $(git root)

I've tried to make this happen many years ago, but I never finished
the ZLE widget that did it. The idea was to bind 'tab' to a function
that would replace an occurrence of ~g in $LBUFFER with the output
of rev-parse--show-toplevel and then delegate to normal tab
expansion.

So now I just have

  hash -d g=$(git rev-parse --show-toplevel)

in a pre-prompt function and get the same effect.

  fishbowl:~/code/salt|develop|debian% ls ~g/debitab

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
i am not in favour of long engagements. they give people the
 opportunity of finding out each other's character before marriage,
 which i think is never advisable.
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: automating git-annex relationships

[martin f krafft]

also sprach Joey Hess j...@kitenet.net [2014-09-09 17:20 +0200]:
 Note that the part after the -- here is just a description, and can be
 any free-form text.

I was going to suggest that there could be another field added to
the protocol, but…

 Recent versions of git-annex have a hidden feature that's used by the
 webapp. The url of an existing git remote can be stored:
 
 git annex initremote albatross type=git 
 location=madduck@albatross:~/family/veronika/photos

… you preempted that!

 And then the same git remote can be set up elsewhere, using that stored
 url:
 
 git annex enableremote albatross

Unfortunately, the requirement for the remote to already exist kinda makes it
hard to use, for two reasons:

  1. The location depends on both sides of the equation, there's not
 always a canonical one.

  2. I'd want to set up the special remote once locally, and then
 use it elsewhere. If I have to set it up elsewhere, I might
 just as well add the remote directly…

 % git annex initremote one type=git location=`pwd`
 (merging origin/git-annex into git-annex...)
 (Recording state in git...)
 initremote one git-annex: could not find existing git remote with 
specified location

 I use mr to set up remotes.
 
 [lib/downloads]
 checkout =
 git clone ssh://j...@git.kitenet.net/srv/git/downloads
 cd downloads
 git remote add website 
 ssh://j...@git.kitenet.net/srv/web/downloads.kitenet.net/.git

Yeah, like Adam.

With the use-case of two machines that are more or less identical,
as well as plenty of SSH hosts out there, which only get a subset of
the repos, I would have to keep a list of remotes centrally
maintained, and possibly a different set for each host as remote URI
depends on the relationship, not a single host. Maybe Git
rewrite rules can help here, as Adam suggests, but it just gets
messy.

The reason I am worrying about this is because rather than having
a single git-annex repo for everything in $HOME, I'd rather have
a different repo for each project I am involved with, and that's
several dozens, so there's a lot of repetitive work ahead, and much
redundancy to be created.

The reason for having separate annexes is quite simply that some of
them are shared with others, while most are not.

So yes, I could have a single annex for $HOME and a few annexes for
sharing, and use views (tags) to select which files appear where.

But views don't (yet) update automatically¹ and there are strict
limitations on filenames², which make views a nice query tool, but
not really a tool for persistent use.

¹) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743820
²) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743794

I would love to have real tagging because I have so many files that
belong to more than one project… :/

/mind mode=wander

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
i believe that the moment is near when by a procedure
 of active paranoiac thought, it will be possible
 to systematise confusion and contribute to
 the total discrediting of the world of reality.
  -- salvador dali
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: integrating an existing git repo in vcsh

[martin f krafft]

also sprach Alan Schmitt  [2016-02-04 00:34 
+1100]:
> I could not find how to do the following in the documentation.
> I already have my .emacs.d under git, and I’m looking into vcsh
> for other configuration files. Is it possible to integrate this
> existing repo in vcsh?

It should be as easy as cloning the repo with vcsh, though I suspect
you'll have to first modify the contents and move all files to
./.emacs.d/, assuming that that's currently the worktree of your Git
repo. vcsh uses ~/ as the worktree, and so your files would
otherwise all be checked out to ~/ instead of ~/.emacs.d/ .

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
in seattle, washington, it is illegal to carry a concealed weapon that
is over six feet in length.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: To use vcsh or not to use vcsh, that is the question

[martin f krafft]

also sprach Samuel Hodgkins  [2017-01-12 17:20 +1300]:
> In comparison to vcsh, I also use myrepos which is excellent at managing a
> set of repositories, and although I haven't used it much it can also do
> commands. I think (but cannot confirm) that it can be extended with
> additional commands just like vcsh and has the benefit of also using normal
> git repositories, enabling easier usage from the command-line.

I think mrsetup already supports vcsh, so you can use it to manage
a combination, as you see fit.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"the well-bred contradict other people.
 the wise contradict themselves."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Dealing with .gitmodules

[martin f krafft]

Hey,

The file .gitmodules (man 5 gitmodules, for use with git-submodule)
is hardcoded to reside in $GIT_WORK_DIR/.gitmodules. As vcsh
repositories all share the same work dir, there's a conflict.

Has anyone come up with a smart way to handle this?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"william blake, you're a dead man!"
   -- nobody
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Dealing with .gitmodules

[martin f krafft]

also sprach Joshua Haase  [2017-03-31 05:37 +0200]:
> > The file .gitmodules (man 5 gitmodules, for use with git-submodule)
> > is hardcoded to reside in $GIT_WORK_DIR/.gitmodules. As vcsh
> > repositories all share the same work dir, there's a conflict.
> 
> Why do you need git modules?

For instance, my awesome config relies on the lain plugin, and
I also use subprojects for e.g. pass, mutt, vim, and others.

How else would you do it? Note that I consider a checkout as part of
a configuration, so I want to decide myself when I pull a new
version and commit that to config, along with possibly required
changes therein. Thus, using myrepos to just recursively pull
doesn't really do what I expect. git-submodules is exactly what
I want.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i can stand brute force, but brute reason is quite unbearable. there
 is something unfair about its use. it is hitting below the
 intellect."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Dealing with .gitmodules

[martin f krafft]

also sprach Kevin Lyda  [2017-03-31 09:50 +0200]:
> Personally I prefer git subtree over git submodules. And that
> said, you're using vcsh which allows for multiple git repos. So
> instead of git submodules, just use additional repos.

I don't think vcsh/myrepos is a good solution, but git-subtree does
seem to work much better. Thanks for the hint.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
the united nations did a poll about food. the only question they asked
was: "could you please give your honest opinion about a solution for
the shortage of food in the rest of the world?" this poll failed
because:
  - in africa they didn't know what food was
  - in eastern-europe they didn't know what honest was
  - in western-europe they didn't know what shortage was...
  - in china they didn't know what opinion was...
  - in the middle-east they didn't know what solution was...
  - in south-america they didn't know what please was...
  - and in the usa they didn't know what "the rest of the world" was...
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home