While my example isn't about puppet, it's about another templating
technology - that is by technical design hence also completely open
source. We have a completely modulirized and completely distributed
deployment scenario that is based on git.
The fundamental core how git addresses the solution i
On 20 Jul 2012, at 19:09, Jeff King wrote:
> On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
>
>> Am 20.07.2012 17:44, schrieb Jeff King:
>>> So I think a suffix like ":d" is probably the least horrible.
>>
>> Not so. It does not work on Windows :-( in the expected way. Trying to
On 20 Jul 2012, at 17:44, Jeff King wrote:
> On Fri, Jul 20, 2012 at 11:49:07AM +0200, Michael Haggerty wrote:
>
>>> This patch moves reflog entries into a special "graveyard"
>>> namespace, and appends a tilde (~) character, which is
>>> not allowed in a valid ref name. This means that the delet
On 22 Jul 2012, at 13:10, Alexey Muranov wrote:
> Sorry if this idea is stupid or if i miss something, but how about putting
> deleted reflogs for
>
> refs/heads/a
> refs/heads/a/b
> refs/heads/a/b/c
>
> to
>
> refs/heads/a@-mm-dd-hhmmss
> refs/heads/a/b@-mm-dd-hhmmss
> refs/heads/a/b
On Sun, Jul 22, 2012 at 01:10:55PM +0200, Alexey Muranov wrote:
> >>> refs/heads/a
> >>> refs/heads/a/b
> >>> refs/heads/a/b/c
> >>>
> >>> will be stored in:
> >>>
> >>> logs/graveyard/refs/heads/a~
> >>> logs/graveyard/refs/heads/a/b~
> >>> logs/graveyard/refs/heads/a/b/c~
> >>>
>
Hi,
I was about to add a configuration for yet another mergetool when I
realized that git gui's mergetool.tcl pretty much duplicates git's
mergetools/* configuration files. Can some one tell me why this is
necessary? I would have expected git gui to simply rely on "git
mergetool" to launch th
On 22 Jul 2012, at 15:14, Jeff King wrote:
> 3. Most importantly, it does not resolve D/F conflicts (it has the
> same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
> will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
> D/F conflicts with a new branch
A common way to track dotfiles with git is using GIT_DIR and
GIT_WORK_TREE to move repository out of ~/.git with something like:
git init --bare ~/.dotfiles
alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git"
dotfiles add ~/.bashrc
dotfiles commit -a -m "add my bashrc"
..
A note on how JGit would work here. Java has none of the fields
that constitute statcrc. I guess we would write zero here when
creating new entries. Git could recognize that when checking status and
simply assume "clean" unless mtime or st_size says otherwise.
For existing entries JGit could e
On Sun, Jul 22, 2012 at 04:40:14PM +0200, Alexey Muranov wrote:
> > 3. Most importantly, it does not resolve D/F conflicts (it has the
> > same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
> > will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
> > D/
Thomas Rast writes:
> The REUC extension stores the stage 1/2/3 data of entries which were
> marked resolved by the user, to enable 'git checkout -m ' to
> restore the conflicted state later.
Yes.
> When a file was deleted on one side of the merge and unmodified on the
> other, merge-recursive
Thiago Farina writes:
> On Sat, Jul 21, 2012 at 4:33 PM, Junio C Hamano wrote:
>> Yes.
>>
>>> Hence does not make sense to ask git to do "push origin master" while
>>> inside feature-work branch.
>> ...
>> No. As long as you know your master is ready and suitable to be
>> published when you ask
Robin Rosenberg writes:
> A note on how JGit would work here. Java has none of the fields
> that constitute statcrc. I guess we would write zero here when
> creating new entries. Git could recognize that when checking status
> and simply assume "clean" unless mtime or st_size says otherwise.
Eve
Junio C Hamano writes:
> Robin Rosenberg writes:
>
>> A note on how JGit would work here. Java has none of the fields
>> that constitute statcrc. I guess we would write zero here when
>> creating new entries. Git could recognize that when checking status
>> and simply assume "clean" unless mtime
Jiang Xin writes:
> Mark strings in git-am, git-rebase, and git-merge for translation.
> And contain fixes for shell gettext extraction and xgettext workaround.
>
> Jiang Xin (7):
> i18n: New keywords for xgettext extraction from sh
> i18n: rebase: mark strings for translation
> i18n: Rewri
Jiang Xin writes:
> -resolvemsg="
> +resolvemsg="$(gettext "
> When you have resolved this problem run \"git rebase --continue\".
> If you would prefer to skip this patch, instead run \"git rebase --skip\".
> To check out the original branch and stop rebasing run \"git rebase
> --abort\".
> -
Jiang Xin writes:
> @@ -249,14 +249,14 @@ struct tree *write_tree_from_memory(struct
> merge_options *o)
>
> if (unmerged_cache()) {
> int i;
> - fprintf(stderr, "BUG: There are unmerged index entries:\n");
> + fprintf(stderr, _("BUG: There are unmer
Martin von Zweigbergk writes:
> After patch 7/7, cherry is used instead of rev-list. Ideally, I would
> have liked to teach "git rev-list --cherry-pick" to somehow use a
> just like cherry does, but I couldn't think of a generic way
> of doing that (in this case, we want to say something like "r
Jeff King writes:
> But what _should_ it show for such an entry? There is no commit to show
> in the reflog walker, but it would still be nice to say "BTW, there was
> a deletion even here". Obviously just skipping it and showing the next
> entry would be better than the current behavior of stopp
mer...@stonehenge.com (Randal L. Schwartz) writes:
>> "Darek" == Darek Bridges writes:
>
> Darek> I use git for many things, but I am trying to work out the
> Darek> workflow to use git for deployment.
>
> Don't.
Yeah, "don't think 'git checkout' is a way to 'deploy'". Using Git
as a transp
On Saturday 21 July 2012 10:44:37 Jonathan Nieder wrote:
> Florian Achleitner wrote:
> > On Saturday 21 July 2012 09:48:34 Jonathan Nieder wrote:
> >> To sum up: I think we should just stick to pipes --- why all this fifo
> >> complication?
> >
> > People didn't like pipe variant (prexec_cb not be
Hi!
Refering to Jonathan's concerns in Saturday night's IRC log:
> [22:59:34] barrbrain, flyingflo: I'm worried about the remote
helper project
> [23:00:05] someone needs to review remote-svn.c to catch things
like that refspec issue which should be straightforward to an experienced eye
Let
Thomas Rast writes:
> Hum, I'm a bit lost now.
>
> What is the status quo? I take it JGit does not have any of ctime, dev,
> ino etc., and either leaves the existing value or puts a 0
> an argument in favor of splitting stat_crc into its fields again?
A difference is that JGit already has s
Hi,
Florian Achleitner wrote:
> On Windows, processses are not forked but spawned from new and therefore
> can't
> inherit pipe file descriptors.
Ok, this is what I didn't understand (and still don't understand).
Yes, on Windows processes are spawned instead of forked. But does
that mean the
The latest maintenance release Git v1.7.11.3 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
a10c420e4d9152d6059f41825904cfac3062b135 git-1.7.11.3.tar.gz
41500708e87787d6139de413c4da916
Git for Windows now ships with the new Git icon from git-scm.com. Use that
icon file instead of the old procedurally drawn one.
Signed-off-by: Sebastian Schuberth
---
gitk-git/gitk | 49 ++---
1 file changed, 26 insertions(+), 23 deletions(-)
diff --g
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
I think we are more or less done for this cycle except for a handful
of topics that are to be rerolled, even though I haven't tagged the
tip of
Hi,
Florian Achleitner wrote:
> After several mailing iterations, showing me that I was wrong, I found what
> the right point is, namely that the remote helper writes references to a
> really private dir in refs//, it doesn't touch anything else,
> and
> by advertising the 'refspec' capabilit
Hi Junio,
This is a series of two patches: the first avoids alignment faults
that were making git either slow on Alpha machines or crashy,
depending on the machine's configuration, and the second patch is a
cosmetic nit noticed while reviewing the first.
Patches are based against
30ae47b4 remo
With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
access 32-bit chunks of memory one byte at a time on arches that
prefer that:
#define get_be32(p)( \
(*((unsigned char *)(p) + 0) << 24)
't' is currently always a numeric constant, but it can't hurt to
prepare for the day that it becomes useful for a caller to pass in a
more complex expression.
Suggested-by: Linus Torvalds
Signed-off-by: Jonathan Nieder
---
Clarified subject line. No other change.
Thanks for reading.
block-sh
When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without
specifying where it should put its output and the output ends up in
./sha1.s. Confusing.
Add an -o option to the .s rule to fix this. We were already doing
that for most compiler invocations but had forgotten it for the
assembl
Hi Dmitry,
Junio C Hamano wrote:
>> Dmitry Ivankov writes:
>>> "from $null_sha1" and "merge $empty_branch" are already allowed so
>>> allow "merge $null_sha1" command too.
>>
>> Would accepting such a "merge oops-do-not-do-anything" allow
>> exporters' job to be simpler?
>
> Good question.
I th
Hi Andrew,
In April, you wrote a nice patch[1] for the svn-fe(1) manpage
clarifying some of its limitations. I was hoping to offer some
patches to squash in to polish some of its more confusing edges and
then apply it, but time for polishing ended up being scarce.
Can you remind me of the curren
On Sun, Jul 22, 2012 at 7:22 AM, Sebastian Schuberth
wrote:
> Hi,
>
> I was about to add a configuration for yet another mergetool when I realized
> that git gui's mergetool.tcl pretty much duplicates git's mergetools/*
> configuration files. Can some one tell me why this is necessary? I would
> h
2012/7/23 Junio C Hamano :
> I do not understand why many of these have Stefano's S-o-b in them.
> If you are relaying what Stefano originally wrote, then the author
> (i.e. "From: ") and the first S-o-b would say Stefano, and your
> S-o-b will follow it, but that is probably not the case.
> I'll d
Eliminate a global variable and File::Find usage by building upon
basename() and glob() instead.
Signed-off-by: David Aguilar
---
git-difftool.perl | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index c079854..
Organize the script so that it has a single main() function which
calls out to dir_diff() and file_diff() functions. This eliminates
"dir-diff"-specific variables that do not need to be calculated when
performing a regular file-diff.
Signed-off-by: David Aguilar
---
git-difftool.perl | 128 +
Shorten the "my" declaration for all of the option-specific variables
by wrapping all of them in a hash. This makes also gives us a place
to specify default values, should we need them.
Signed-off-by: David Aguilar
---
git-difftool.perl | 55 +++--
Teach difftool's --dir-diff mode to use symlinks to represent
files from the working copy, and make it the default behavior
for the non-Windows platforms.
Using symlinks is simpler and safer since we do not need to
worry about copying files back into the worktree.
The old behavior is still availab
On Sun, Jul 22, 2012 at 8:42 PM, David Aguilar wrote:
> ... This makes also gives us a place to specify default values
Oops, please drop the word "makes" from the commit message here if you
apply this, or I'll fix it in a re-roll if review finds other issues.
Thanks,
--
David
--
To unsubscribe
Teach the difftool script to use symlinks when doing
directory diffs in --dir-diff mode.
This is v2 of the patch because I had a typo in one of the
commit messages and gmail ate 4/5 in the last round.
David Aguilar (5):
difftool: Simplify print_tool_help()
difftool: Eliminate global variables
Eliminate a global variable and File::Find usage by building upon
basename() and glob() instead.
Signed-off-by: David Aguilar
---
Same as before, resending because gmail ate patch 4/5
git-difftool.perl | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git
Organize the script so that it has a single main() function which
calls out to dir_diff() and file_diff() functions. This eliminates
"dir-diff"-specific variables that do not need to be calculated when
performing a regular file-diff.
Signed-off-by: David Aguilar
---
Same as before, resending beca
The "diffall" name was left over from when this functionality was part of
the "git-diffall" script in contrib/. Make the naming consistent.
Signed-off-by: David Aguilar
---
Reworded the commit message to get through gmail filters.
git-difftool.perl | 2 +-
1 file changed, 1 insertion(+), 1 del
Teach difftool's --dir-diff mode to use symlinks to represent
files from the working copy, and make it the default behavior
for the non-Windows platforms.
Using symlinks is simpler and safer since we do not need to
worry about copying files back into the worktree.
The old behavior is still availab
Shorten the "my" declaration for all of the option-specific variables
by wrapping all of them in a hash. This also gives us a place to
specify default values, should we need them.
Signed-off-by: David Aguilar
---
Fixed typo in the commit message
git-difftool.perl | 55 +
What is the best way to compile git without nls support?
It doesn't seem to be possible with configure, though running "make
NO_GETTEXT=y" seems to work. Is there a more elegant way to do it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano wrote:
> mer...@stonehenge.com (Randal L. Schwartz) writes:
>
>>> "Darek" == Darek Bridges writes:
>>
>> Darek> I use git for many things, but I am trying to work out the
>> Darek> workflow to use git for deployment.
>>
>> Don't.
>
> Yeah, "don'
Jonathan Nieder writes:
> This is a series of two patches: the first avoids alignment faults
> that were making git either slow on Alpha machines or crashy,
> depending on the machine's configuration, and the second patch is a
> cosmetic nit noticed while reviewing the first.
> ...
> Thoughts?
>
Jiang Xin writes:
> 2012/7/23 Junio C Hamano :
>> I do not understand why many of these have Stefano's S-o-b in them.
>> If you are relaying what Stefano originally wrote, then the author
>> (i.e. "From: ") and the first S-o-b would say Stefano, and your
>> S-o-b will follow it, but that is proba
Junio C Hamano wrote:
> Thanks.
>
> Did somebody actually compiled Git for Alpha, and even more
> surprisingly on a big-endian variant of one?
Logs from building for Alpha and running the test suite are here:
http://buildd.debian-ports.org/status/logs.php?pkg=git&arch=alpha
The big-endian part
David Aguilar writes:
> + # Do not copy back files when symlinks are used
> + if ($symlinks) {
> + exit(0);
> + }
> +
Isn't this a bit risky, depending on the behaviour of the tool that
eventually lead the user to invoke his favorite editor to muck with
the files in the t
Daniel Graña writes:
> A common way to track dotfiles with git is using GIT_DIR and
> GIT_WORK_TREE to move repository out of ~/.git with something like:
>
> git init --bare ~/.dotfiles
> alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git"
>
> dotfiles add ~/.bashrc
> dotfile
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> Thanks.
>>
>> Did somebody actually compiled Git for Alpha, and even more
>> surprisingly on a big-endian variant of one?
>
> Logs from building for Alpha and running the test suite are here:
>
> http://buildd.debian-ports.org/status/logs.php?
Jonathan Nieder writes:
> When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without
> specifying where it should put its output and the output ends up in
> ./sha1.s. Confusing.
>
> Add an -o option to the .s rule to fix this. We were already doing
> that for most compiler invocations
David Aguilar writes:
> Teach the difftool script to use symlinks when doing
> directory diffs in --dir-diff mode.
>
> This is v2 of the patch because I had a typo in one of the
> commit messages and gmail ate 4/5 in the last round.
FWIW, I received all including 4/5 in my inboxes (at pobox and
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The big-endian part was just my idiocy, sorry.
>
> Hrm, do we want an update log message for 1/2 then?
Hm, I thought all the crazy had been eliminated already.
*looks again*
I guess "using a single 32-bit load" makes it sound like it's using a
On Sun, Jul 22, 2012 at 10:14 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Teach the difftool script to use symlinks when doing
>> directory diffs in --dir-diff mode.
>>
>> This is v2 of the patch because I had a typo in one of the
>> commit messages and gmail ate 4/5 in the last round.
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> The big-endian part was just my idiocy, sorry.
>>
>> Hrm, do we want an update log message for 1/2 then?
>
> Hm, I thought all the crazy had been eliminated already.
>
> *looks again*
>
> I guess "using a single 32-
Teach difftool's --dir-diff mode to use symlinks to represent
files from the working copy, and make it the default behavior
for the non-Windows platforms.
Using symlinks is simpler and safer since we do not need to
worry about copying files back into the worktree.
The old behavior is still availab
On 23.07.2012 05:42, David Aguilar wrote:
Organize the script so that it has a single main() function which
calls out to dir_diff() and file_diff() functions. This eliminates
"dir-diff"-specific variables that do not need to be calculated when
performing a regular file-diff.
Funny, I just have
On Sun, Jul 22, 2012 at 11:13 PM, Sebastian Schuberth
wrote:
> On 23.07.2012 05:42, David Aguilar wrote:
>
>> Organize the script so that it has a single main() function which
>> calls out to dir_diff() and file_diff() functions. This eliminates
>> "dir-diff"-specific variables that do not need to
Git for Windows now ships with the new Git icon from git-scm.com. Use that
icon file instead of the old procedurally drawn one if it exists.
Signed-off-by: Sebastian Schuberth
---
gitk-git/gitk | 49 ++---
1 file changed, 26 insertions(+), 23 deletions
block-sha1/ is fast on most known platforms. Clarify the Makefile to
be less misleading about that.
Early versions of block-sha1/ explicitly relied on fast htonl() and
fast 32-bit loads with arbitrary alignment. Now it uses those on some
arches but the default behavior is byte-at-a-time access f
On Mon, Jul 23, 2012 at 8:21 AM, David Aguilar wrote:
>> Funny, I just have prepared a patch along the same lines so that one can
>> call git-difftool -h and --tool-help also outside a repository, see below.
>> Does you patch offer the same? If so, I'll drop mine.
>
> It *should*. I did not consi
On Sun, Jul 22, 2012 at 11:30 PM, Sebastian Schuberth
wrote:
> On Mon, Jul 23, 2012 at 8:21 AM, David Aguilar wrote:
>
>>> Funny, I just have prepared a patch along the same lines so that one can
>>> call git-difftool -h and --tool-help also outside a repository, see below.
>>> Does you patch off
On Mon, Jul 23, 2012 at 8:44 AM, David Aguilar wrote:
>> Well, I'm not asking for a test. From my side, I'd be happy if you
>> could just try it and confirm that it works, as I currently cannot
>> easily apply your patch.
>
> Heheh.. I was hoping you could provide a test ;-)
;-)
> I just tried
68 matches
Mail list logo
