> -----Original Message----- > From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] > Sent: Monday, September 17, 2012 9:21 AM > To: Mestnik, Michael J - Eagan, MN - Contractor > Cc: Junio C Hamano; Johannes Sixt; git@vger.kernel.org > Subject: Re: Using Format/export-subst Howto. > > Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit > 17.09.2012 16:08: > > > >> -----Original Message----- > >> From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] > >> Sent: Monday, September 17, 2012 8:45 AM > >> To: Mestnik, Michael J - Eagan, MN - Contractor > >> Cc: Junio C Hamano; Johannes Sixt; git@vger.kernel.org > >> Subject: Re: Using Format/export-subst Howto. > >> > >> Mestnik, Michael J - Eagan, MN - Contractor venit, vidit, dixit > >> 17.09.2012 14:12: > >>> > >>>> -----Original Message----- > >>>> From: Junio C Hamano [mailto:gits...@pobox.com] > >>>> Sent: Friday, September 14, 2012 4:24 PM > >>>> To: Michael J Gruber > >>>> Cc: Johannes Sixt; Mestnik, Michael J - Eagan, MN - > >>>> Contractor; git@vger.kernel.org > >>>> Subject: Re: Using Format/export-subst Howto. > >>>> > >>>> Michael J Gruber <g...@drmicha.warpmail.net> writes: > >>>> > >>>>> you need to "rm file && git checkout file"). If the user > >>>> has to update > >>>>> $Id$ to match the current sha1 > >>>>> (by remembering to do a more forceful checkout than > >>>> checkout -f) then > >>>>> one half of that feature is useless. > >>>> > >>>> As if there is any value in "$Id$" _feature_. It's a > >> checkbox item, > >>>> nothing more ;-). > >>>> > >>> > >>> I agree here, $Id$ is much more useful in rcs/cvs. That's > >> why I chose to dive into export-subst, because I wanted my > >> output to not only contain the uniq Id of the script but also > >> the time and user of the last edit. > >>> > >>> I'm going to read up on export today. Just for context I'm > >> using git to manage daily cron scripts, run on about 1,000 > >> hosts, located on NFS. I've moved the editing of the scripts > >> into user's home directories as I'm a fan of not using > >> editors on live data. The key point is that when sudoing to > >> the shared user who manages the files the commands run should > >> be minimal and "pushd; ln -s ... .git; git pull; rm .git; > >> popd;" works well. If I can replace this with something that > >> would populate these fields that would be awesome. > >> > >> I'm not completely sure about the setup, but something like > >> > >> GIT_DIR=fromthisrepo git archive usethisbranchortag | > >> git tar -xf- -C thereyougo > >> > > Yes, that's about what the man page says. I though I could > pass --keep-newer-files to tar and that would prevent files > from being re-created, but a "git archive --format=tar HEAD | > tar -tvv" indicates that every file has the current date/time > and not, for example, the time of the last commit that > modified that file. Not only would pushing every file be > undesirable it would also cause every server to pull every > file and that's unacceptable. Another down side, or perhaps > this is the downside, to this method is that it lacks any > form of merge capability and will destroy local changes. > > I thought it's only a few files and you don't care about merging (in > sudo), only about deploying a checkout, since you're removing > the git dir. > Allow me to explain. There was an issue with copying the .git folder to every host, we literally don't have the space for that and I wonder what happens when these files grow by a few hundred k. I had put in the symlink, but our replicator script was chocking on it. Thus I've resorted to not only using a symlink, but also removing it when not in use. Correcting these issues is lower priority then making the logs have all the information they need.
Merging has been done when edits are needed ASAP and git becomes an after thought. I've done pushes from the live files too, though it is something that happens after an emergency. I know I've got a rather strange environment, most of it surprises me as well. > > It looks like I'll be doing this in a hook. > > > > BTW: I couldn't find "git tar", if it exists that might be > the way for me... Depending on what it would do. > > Oh yeah. Done too much git work lately. I know I keep using "git help > foo" rather than "man foo", but this one is new :) > > I just meant tar. > > Michael > Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 michael.j.mest...@usps.gov itenterprisesystemsmonitor...@usps.gov -- 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/majordomo-info.html
