* Re: [PATCH v2] t/t9001-send-email.sh: fix '&&' chain in some tests
From: Junio C Hamano @ 2011-01-04 23:56 UTC (permalink / raw)
To: Antonio Ospite; +Cc: git, Jonathan Nieder
In-Reply-To: <1294174618-14571-1-git-send-email-ospite@studenti.unina.it>
Thanks.
^ permalink raw reply
* What's cooking in git.git (Jan 2011, #01; Tue, 4)
From: Junio C Hamano @ 2011-01-04 23:50 UTC (permalink / raw)
To: git
A happy new year.
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I'll start paying much less attention to any new features and enhancements
and shift the focus almost entirely on trivial fixes and regressions from
now on. Hopefully lists will do the same and we can have a fairly short
rc period this cycle. Please remind if there are patches that ought to be
in 1.7.4 but are forgotten.
--------------------------------------------------
[New Topics]
* jn/gitweb-no-logo (2010-09-03) 1 commit
(merged to 'next' on 2011-01-04 at a5d186c)
+ gitweb: make logo optional
Seemed trivial but came a bit too late for the cycle.
* cb/setup (2010-12-27) 1 commit
- setup: translate symlinks in filename when using absolute paths
Seemed trivial but came a bit too late for the cycle.
--------------------------------------------------
[Stalled]
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
--------------------------------------------------
[Cooking]
* mg/cvsimport (2010-12-29) 2 commits
- cvsimport: handle the parsing of uppercase config options
- cvsimport: partial whitespace cleanup
Reviewed twice in the past and seemed sane. Will merge to 'next' and then
to 'master' before -rc1.
* ae/better-template-failure-report (2010-12-18) 1 commit
- Improve error messages when temporary file creation fails
* jc/unpack-trees (2010-12-22) 2 commits
- unpack_trees(): skip trees that are the same in all input
- unpack-trees.c: cosmetic fix
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
- cherry-pick/revert: add support for -X/--strategy-option
* jn/perl-funcname (2010-12-27) 2 commits
- userdiff/perl: catch BEGIN/END/... and POD as headers
- diff: funcname and word patterns for perl
* pw/convert-pathname-substitution (2010-12-22) 2 commits
- t0021: avoid getting filter killed with SIGPIPE
- convert filter: supply path to external driver
Trivial. Will merge to 'next' and then to 'master' before -rc1.
* rj/test-fixes (2010-12-14) 4 commits
- t4135-*.sh: Skip the "backslash" tests on cygwin
- t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
- t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
- t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
I don't think people on different vintage of Cygwin agreed they are good
workarounds---please correct me if I am mistaken.
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Will be rerolled (Heiko, 2010-12-23)
* jn/svn-fe (2010-12-06) 18 commits
- vcs-svn: Allow change nodes for root of tree (/)
- vcs-svn: Implement Prop-delta handling
- vcs-svn: Sharpen parsing of property lines
- vcs-svn: Split off function for handling of individual properties
- vcs-svn: Make source easier to read on small screens
- vcs-svn: More dump format sanity checks
- vcs-svn: Reject path nodes without Node-action
- vcs-svn: Delay read of per-path properties
- vcs-svn: Combine repo_replace and repo_modify functions
- vcs-svn: Replace = Delete + Add
- vcs-svn: handle_node: Handle deletion case early
- vcs-svn: Use mark to indicate nodes with included text
- vcs-svn: Unclutter handle_node by introducing have_props var
- vcs-svn: Eliminate node_ctx.mark global
- vcs-svn: Eliminate node_ctx.srcRev global
- vcs-svn: Check for errors from open()
- vcs-svn: Allow simple v3 dumps (no deltas yet)
- vcs-svn: Error out for v3 dumps
Some RFC patches, to give them early and wider exposure. Perhaps drop
these during the -rc period?
* nd/struct-pathspec (2010-12-15) 21 commits
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
- Exhibit merge bug that clobbers index&WT
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
^ permalink raw reply
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Junio C Hamano @ 2011-01-04 23:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Matthieu Moy, Vallon, Justin, Robin H. Johnson,
git@vger.kernel.org
In-Reply-To: <20110104225826.GA2122@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Matthieu Moy wrote:
>> "Vallon, Justin" <Justin.Vallon@deshaw.com> writes:
>
>>> --- a/t/t3404-rebase-interactive.sh
>>> +++ b/t/t3404-rebase-interactive.sh
>>> @@ -71,8 +71,9 @@ test_expect_success 'setup' '
>>> # "exec" commands are ran with the user shell by default, but this may
>>> # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
>>> # to create a file. Unseting SHELL avoids such non-portable behavior
>>> -# in tests.
>>> +# in tests. It must be exported for it to take effect where needed.
>>> SHELL=
>>> +export SHELL
>>
>> (my bad, I wrote this SHELL= without exporting it. Since bash
>> re-exports already exported variables when they are assigned, and my
>> /bin/sh points to bash, I didn't notice)
>
> Isn't that how export works in all Bourne-style shells? For example:
>
> $ env var=outside dash -c '
> var=inside;
> dash -c "echo \$var"
> '
> inside
> $
>
> Maybe in the failing case SHELL was not exported but just set to
> /bin/false in .bashrc or similar?
Thanks, you saved me some time responding ;-)
Matthieu's diagnosis is only half correct in that bash is why he didn't
notice the problem, but if in this sequence
var=foo
export var
var=bar
some-command
some-command does not see "bar" as the value of environment variable
"var", your shell is not POSIX (there is no such thing as "re-exporting").
Either a variable is marked with the export attribute, in which case the
processes spawned from the shell sees the value of the then-current shell
variable in their environments, or they don't for shell variables that are
not marked with the export attribute.
The real reason the problem went unnoticed was because bash automatially
marks SHELL with the export attribute.
Because POSIX shells are required to mark variables they inherit from the
environment with the export attribute, your tests will run with SHELL
exported to the environment if your usual shell is bash (i.e. SHELL is
already exported to processes it spawns), even if you use another POSIX
shell to run your git and tests. That makes the issue doubly harder to
notice.
^ permalink raw reply
* Re: [PATCH 0/2] gitweb: make logo optional
From: Eric Wong @ 2011-01-04 23:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, John 'Warthog9' Hawley, Jakub Narebski
In-Reply-To: <20110104050206.GA8280@burratino>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> These patches were last seen in the instaweb 1.7.1 maintenance
> thread[1] but I believe they are independently useful. The
> idea is to allow disabling the logo in gitweb.
>
> Jonathan Nieder (2):
> gitweb: skip logo in atom feed when there is none
> gitweb: make logo optional
This series looks good to me (especially considering my strong
dislike of logos/icons on the web :>)
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/3] Fixes bug: git-svn: svn.pathnameencoding is not respected with dcommit/set-tree
From: Eric Wong @ 2011-01-04 23:20 UTC (permalink / raw)
To: Zapped; +Cc: Thomas Rast, git
In-Reply-To: <201101041818.09365.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> Zapped wrote:
> > git-svn dcommit/set-tree fails when svn.pathnameencoding is set for native OS encoding (e.g. cp1251 for Windows) though git-svn fetch/clone works well
>
> I'll let Eric judge whether loading the encoding here is the right
> fix, but here too the commit message states only what is broken, not
> why you fixed it that way. Can you elaborate a bit?
>
> Also, this should be easy to cover with a test case, can you make one?
I second Thomas's requests. I'm also a bit disappointed the original
option is missing tests, especially since not many people are likely to
use it.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Jonathan Nieder @ 2011-01-04 22:58 UTC (permalink / raw)
To: Matthieu Moy
Cc: Vallon, Justin, Robin H. Johnson, Junio C Hamano,
git@vger.kernel.org
In-Reply-To: <vpqhbdoxpzp.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> "Vallon, Justin" <Justin.Vallon@deshaw.com> writes:
>> --- a/t/t3404-rebase-interactive.sh
>> +++ b/t/t3404-rebase-interactive.sh
>> @@ -71,8 +71,9 @@ test_expect_success 'setup' '
>> # "exec" commands are ran with the user shell by default, but this may
>> # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
>> # to create a file. Unseting SHELL avoids such non-portable behavior
>> -# in tests.
>> +# in tests. It must be exported for it to take effect where needed.
>> SHELL=
>> +export SHELL
>
> (my bad, I wrote this SHELL= without exporting it. Since bash
> re-exports already exported variables when they are assigned, and my
> /bin/sh points to bash, I didn't notice)
Isn't that how export works in all Bourne-style shells? For example:
$ env var=outside dash -c '
var=inside;
dash -c "echo \$var"
'
inside
$
Maybe in the failing case SHELL was not exported but just set to
/bin/false in .bashrc or similar?
^ permalink raw reply
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Matthieu Moy @ 2011-01-04 22:28 UTC (permalink / raw)
To: Vallon, Justin
Cc: 'Robin H. Johnson', Junio C Hamano, git@vger.kernel.org
In-Reply-To: <982E526FA742C94E9AC26DA766FD07090A3399@NYCMBX3.winmail.deshaw.com>
"Vallon, Justin" <Justin.Vallon@deshaw.com> writes:
> How was SHELL=/bin/false causing problems? Is git using $SHELL?
The explanation is in the comment right above the modification in the
patch. "user's shell" can be read as "$SHELL":
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -71,8 +71,9 @@ test_expect_success 'setup' '
> # "exec" commands are ran with the user shell by default, but this may
> # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
> # to create a file. Unseting SHELL avoids such non-portable behavior
> -# in tests.
> +# in tests. It must be exported for it to take effect where needed.
> SHELL=
> +export SHELL
(my bad, I wrote this SHELL= without exporting it. Since bash
re-exports already exported variables when they are assigned, and my
/bin/sh points to bash, I didn't notice)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git repo corruption
From: Neal Kreitzinger @ 2011-01-04 21:42 UTC (permalink / raw)
To: Levend Sayar; +Cc: git
In-Reply-To: <AANLkTi=TSy1WQZARNQgGfPiV93hQ-xmCTip75JAixgDB@mail.gmail.com>
On 1/4/2011 3:10 AM, Levend Sayar wrote:
> Hi, all.
>
> We have a repo on a corporate server. The sysadmin changed access
> rights of files on our repo by accedant.
> Some directories have 2750 acces rights before, but he changed as
>
> chmod -R 2770 *
>
> Now when you make git status, every file that is tracked by git is said as
>
> changed but not updated
>
> So is there a way to get this back to normal ?
>
> TIA
>
> _lvnd_
> (^_^)
I assume the correct permissions for your tracked files should be 2750?
If so, then here's what I would do:
1. First make a copy of your repo and test these steps on the copy:
e.g. bare repo: cp -rvp repo.git repocopy.git
non-bare-repo: cp -rvp worktree worktreecopy
2. Then cd to the parent of the objects dir in you git repo:
e.g. bare repo: cd repocopy.git
non-bare repo: cd worktreecopy/.git
3. Then change the permissions of your objects dir:
chmod -R 2750 objects
4. Validate the results. Your permissions should match again.
5. If it worked, then do it on the real repo.
v/r,
Neal
^ permalink raw reply
* Re: developing a modified Linux-style workflow
From: Neal Kreitzinger @ 2011-01-04 21:19 UTC (permalink / raw)
To: git; +Cc: Neal Kreitzinger, git
In-Reply-To: <344D6422-8F2B-4545-A680-06F434C17F5B@at.or.at>
On 1/4/2011 1:01 PM, Hans-Christoph Steiner wrote:
>
> On Dec 13, 2010, at 11:16 AM, Neal Kreitzinger wrote:
>
>> "Hans-Christoph Steiner" <hans@at.or.at> wrote in message
>> news:7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@at.or.at...
>>>
>>> Hey all,
>>>
>>> (and my second post on this list...)
>>>
>>> I've gotten pretty good at git, and its helping me already with managing
>>> the very odd workflows I have with the software I work a lot on
>>> called Pd
>>> (http://puredata.info). My role in Pd development is like a Linux
>>> lieutenant.
>>>
>>> I also the main dev for an app called Pd-extended, which is based on Pd.
>>> Now I'm stuck trying to figure out how to use git to match my current
>>> workflow for Pd-extended, which is a kind of long-lived branch, almost
>>> like a friendly fork. So its kind of close to the Linux workflow with me
>>> as a lieutenant, but not quite.
>>>
>>> What makes it tricky is that I make releases directly from my repo that
>>> are widely used. So my repo is both lieutenant and dictator at the same
>>> time. So that's where I am stumped. I want to be able to rebase and
>>> push to a public repo, but that would be stupid. So there has got to be
>>> another way.
>>>
>>> .hc
>>>
>> I don't think pushing to a public repo is stupid. You could create a bare
>> repo with a Pd branch and Pd-extended branch that contain the production
>> versions of Pd and Pd-extended. The main reason our shop chose git is
>> because it allows us to easily have multiple concurrent versions of
>> production by having a branch for each of our custom versions. These
>> versions eventually get merged together into a major release, but in the
>> meantime they are longlived branches representing the productional
>> customized system for each major customer.
>>
>> *If* you end up merging Pd and Pd-extended at some point, then you could
>> have another branch for that, e.g. master or Pd-master or whatever. BTW,
>> you do not have to use master as the representative of your final merged
>> work so don't think that is the way you HAVE to do it. It's just the
>> default, and a common practice for systems with a single version of
>> production. Master can become vestigial or secondary, if you choose to
>> create a new branch called Pd-master, etc. to represent your eventual
>> merges
>> of Pd and Pd-extended.
>
>
> For me the biggest feature that I am looking for is the automatic
> merging of commits, and second, having a branch that puts my collection
> of patches/commits ahead of the Pd master so that its easy to manage the
> patches. I don't think I see how I could do that with this multiple
> branches idea. Is that possible?
>
I have _no_ experience using patches (in git or otherwise) to manage
change control, ie. git-am, git-format-patch, etc., as of yet...
That being said, FWIW, here is a suggestion based on the following
assumptions:
a. It sounds like Pd and Pd-extended only get merged once-in-a-while
(infrequently).
b. Pd is the main version in use, and Pd-extended is a future version
or a not-yet-widely-used version.
c. Pd-extended is based on Pd, but since the inception of Pd-extended
both Pd and Pd-extended have advanced (diverged).
Assuming that is the case, this is similar to what our shop does. We
have a production system X12 and a new system X13 that is based on X12.
Periodically, bugfixes and enhancements from X12 need to be merged
into X13. Here's how we do it:
1. Identify the range of commits in X12 that are not yet in X13 (new
X12 commits since the last X12-X13 merge):
$ git log
sha1-of-last-X12-commit-alreadyMERGED-into-X13..sha1-of-newest-X12-commit-you-want-MERGED-into-X13
--format="%h%d %s"
>/somepath/whereIkeepstuff/X12-X13-MRG.01-REBASE-TO-DO.lst
2. Identify any commits in the X12 commits that you do not want merged
into X13.
3. Create a throw-away-integration-branch which is a copy of X12:
$ git checkout X12
$ git branch X12-Squash
4. Create a throw-away-integration-branch which is a copy of X13:
$ git checkout X13
$ git checkout X13-Merge-X12
5. Squash the X12 merge series into a single commit:
$ git checkout X12-Squash
$ git reset --hard sha1-of-newest-X12-commit-you-want-MERGED-into-X13
(in case its not the head commit of the branch)
$ git rebase -i sha1-of-last-X12-commit-alreadyMERGED-into-X13
(interactive rebase to squash the X12 "new commits" series)
#comment out any commits that you don't want in X13, if applicable.
put an "s" next to all the other commits to squash them.
6. Cherry pick the X12 squashed commit onto X13:
$ git checkout X13-Merge-X12
$ git cherry-pick --edit X12-Squash
resolve any conflicts
review what got merged automatically and make sure its right (git
doesn't know about conflicts in logic)
7. Merge results into real X13:
$ git checkout X13
$ git merge --ff-only X13-Merge-X12
8. Create a test copy of the bare repo of X13:
$ cp -rvp X13.git QA-X13.git
9. Push to QA copy of X13 repo: (make sure your push results are ok)
$ git push QA-X13-remotename HEAD
review in gitk, etc. to verify it is correct
10. Push to real X13 repo:
$ git push X13-remotename HEAD
review results
notify others of update.
Note: you can have X12 and X13 in separate bare repos if you want, or as
branches in a single bare repo. If X12 and X13 are in separate bare
repos, then you can use an 'integration manager' repo to remote to them
and pull their changes into integration branches. That's actually how
our shop currently does it because the X13 people do not maintain X12.
The steps above are for a single bare repo in order to save on the
number of steps in the example.
Hope this helps. If my assumptions are incorrect then we might have
other merge techniques that may be applicable...
v/r,
Neal
^ permalink raw reply
* Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules
From: Marcin Wiśnicki @ 2011-01-04 21:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrmkfphh.fsf@alter.siamese.dyndns.org>
On Tue, 04 Jan 2011 11:17:14 -0800, Junio C Hamano wrote:
>> Patterns that do not match but should:
>> d2/*
>
> This shouldn't match unless it appears in d1/.gitattributes.
>
> The presense of '/' makes the pattern anchored to the directory it
> appear in, and .git/info/attributes is taken as being at the top level.
>
After more carefully re-reading gitignore(5) I think that now I get it.
I presume that is is not possible to match certain pattern occurring
*anywhere* in the path.
Would it be possible to extend pattern format to include double-star
wildcard that matches anything including slashes ?
Like: **/whatever/**
Many tools (in java at least) and libraries support such extension to
globs. Unfortunately standard fnmatch(3) that's used by git is not one of
them, but glibc's implementation looks portable and self-contained so it
could be included and modified.
>> d2/
>> d2
>
> These shouldn't for the same reason.
>
>> d1/d2
>> /d1/d2
>
> We somehow don't do leading path match like we do for gitignore, but I
> do not think this was intended. My gut feeling is that these should
> match.
>
> The thinking back, when we wrote the code, could have been that, unlike
> gitignore that maintains only one bit (either "ignored" or "not"),
> attributes are richer and giving the same attribute (say "whitespace
> checking criteria") to files inside a directory and the containing
> directory itself was nonsensical. But if that was the reason, it is
> faulty, as we do not track directories anyway.
>
> Wouldn't it be sufficient to teach attr.c:path_matches() that a pattern
> could also match with leading path? That would automatically cover the
> case where a pattern is terminated with a slash, as pattern "d/e/" would
> never match path "d/e" but does match "d/e/f"?
^ permalink raw reply
* [PATCH v2] t/t9001-send-email.sh: fix '&&' chain in some tests
From: Antonio Ospite @ 2011-01-04 20:56 UTC (permalink / raw)
To: git; +Cc: Antonio Ospite, Junio C Hamano, Jonathan Nieder
t/README recommends chaining test assertions.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
Hi sorry for the delay,
the only change wrt. v1 is the use of test_might_fail with
git config --unset as requested by Jonathan.
Note that in t9001-send-email.sh and other tests git config --unset is used
without the test_might_fail handler some other times, you might wat to check
this.
Thanks and best regards,
Antonio Ospite
http://ao2.it
t/t9001-send-email.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 1dc4a92..ace3c78 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -265,7 +265,7 @@ test_expect_success $PREREQ 'Author From: in message body' '
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
- sed "1,/^\$/d" < msgtxt1 > msgbody1
+ sed "1,/^\$/d" < msgtxt1 > msgbody1 &&
grep "From: A <author@example.com>" msgbody1
'
@@ -276,7 +276,7 @@ test_expect_success $PREREQ 'Author From: not in message body' '
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
- sed "1,/^\$/d" < msgtxt1 > msgbody1
+ sed "1,/^\$/d" < msgtxt1 > msgbody1 &&
! grep "From: A <author@example.com>" msgbody1
'
@@ -298,7 +298,7 @@ test_expect_success $PREREQ 'Invalid In-Reply-To' '
--in-reply-to=" " \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
- 2>errors
+ 2>errors &&
! grep "^In-Reply-To: < *>" msgtxt1
'
@@ -617,7 +617,7 @@ EOF
"
test_expect_success $PREREQ '--suppress-cc=sob' '
- git config --unset sendemail.cccmd
+ test_might_fail git config --unset sendemail.cccmd &&
test_suppression sob
'
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Robin H. Johnson @ 2011-01-04 20:35 UTC (permalink / raw)
To: Vallon, Justin; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <982E526FA742C94E9AC26DA766FD07090A3399@NYCMBX3.winmail.deshaw.com>
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
On Tue, Jan 04, 2011 at 09:43:12AM -0500, Vallon, Justin wrote:
> # "exec" commands are ran with the user shell by default, but this may
> # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
> # to create a file. Unseting SHELL avoids such non-portable behavior
>
> Perl's exec and system do not use SHELL (as far as perlfunc states). It uses
> /bin/sh -c "$cmd", or a platform-dependent equivalent.
>
> $SHELL is typically only used when a program wants to invoke a user-shell
> (ie: editor shell-escape, xterm, typescript, screen).
>
> How was SHELL=/bin/false causing problems? Is git using $SHELL?
git-rebase--interactive.sh:
====
${SHELL:-@SHELL_PATH@} -c "$rest" # Actual execution
status=$?
if test "$status" -ne 0
then
warn "Execution failed: $rest"
====
This always triggers with SHELL=/bin/false if SHELL is unset or empty,
SHELL_PATH gets substituted, which tends to be the correct /bin/sh.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: [PATCH 00/31] Refactor rebase
From: Thomas Rast @ 2011-01-04 19:57 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <1293528648-21873-1-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk wrote:
> For the past two months, I have been working on refactoring the rebase
> code. See [1] for background information. I have been trying to polish
> the patch set for some time, but now I don't think I will get much
> further without your help.
Thanks a lot for undertaking this effort! I just finished looking
through the entire series, and it all seems sane to me. Apart from
j6t's reply I think we're mostly nit-picking or agreeing with you, and
this is the first iteration!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC][PATCH] git-send-email: added support for S/MIME
From: Thomas Rast @ 2011-01-04 19:36 UTC (permalink / raw)
To: Roberto Sassu; +Cc: git
In-Reply-To: <1294156930-21367-1-git-send-email-roberto.sassu@polito.it>
Roberto Sassu wrote:
> The script git-send-email.perl has been modified in order to add support
> for messages with S/MIME format.
Does git-am need symmetric support to decode the message?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 26/31] rebase: remember strategy and strategy options
From: Thomas Rast @ 2011-01-04 19:27 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <1293528648-21873-27-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk wrote:
> How to add support for strategy options to interactive rebase?
AFAICS rebase -i currently only uses the strategy when dealing with
multiple parents, i.e., in --preserve-merges mode. I think
git-cherry-pick needs to learn about the -s and -X options, and then
it'll be a simple matter of passing them along.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC][PATCH] git-send-email: added support for S/MIME
From: Junio C Hamano @ 2011-01-04 19:22 UTC (permalink / raw)
To: Roberto Sassu; +Cc: git
In-Reply-To: <1294156930-21367-1-git-send-email-roberto.sassu@polito.it>
Roberto Sassu <roberto.sassu@polito.it> writes:
> ...
> Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
The patch with so many "if ($sign) do this else do that" is too ugly
beyond words. I wonder if the surrounding code can be better
restructured.
^ permalink raw reply
* Re: [RFC/PATCH] Documentation/technical: document quoting API
From: Junio C Hamano @ 2011-01-04 19:21 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder, Jeff King, Dmitry Potapov
In-Reply-To: <20110103063534.GA3661@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> +C-style quoting
> +---------------
> +
> +`quote_c_style` quotes a string in a manner that might be familiar
> +to C programmers. This can be used to quote newlines and tabs in
> +filenames for patches, for example.
> +
> +. if sb and fp are both NULL, it returns the number of bytes needed
> + to hold the quoted version of "name", counting the double quotes
> + around it but not terminating NUL. If "name" does not need quoting,
> + it returns 0.
> +
> +. otherwise, it emits the quoted version of "name" to a stream,
> + strbuf, or both. Output will have enclosing double quotes
> + suppressed if requested with the "no_dq" parameter.
Heh, I didn't know about the "both" case. That is probably unintended
misfeature that would not hurt but would not be useful in practice either
;-)
> +`quote_two_c_style`::
> + Quote two paths (prefix + path) in C-style and concatenate them.
> + One should use this instead of calling `quote_c_style` twice
> + to avoid unsightly quotation marks in the middle.
Just for the record, "Avoid dqdq in the middle" was never the motivation;
you can run two no_dq invocations and put dq around the result yourself.
The main motivation for using this, before the strbuf was widely used, was
to avoid having to allocate memory only to call quote_c_style, because it
happens so often that we have prefix and path as separate strings.
> +`unquote_c_style`::
> + This unwraps what quote_c_style() produces in place,
> + but returns -1 and doesn't touch if the input does not start with
> + a double-quote or otherwise differs from what quote_c_style
> + would have produced. Though note that this function will
> + allocate memory in the strbuf, so calling `strbuf_release`
> + is mandatory regardless of the result `unquote_c_style` returns.
s/Though note/Note/ perhaps?
> +Quoting for the shell
> +---------------------
> +
> +`sq_quote` copies its argument quoted for the shell safety.
> +Any single quote is replaced with '\'', any exclamation point
> +is replaced with '\!', and the whole thing is enclosed in a
> +single-quote pair.
> +
> +For example, if you are passing the result to `system()` as an
> +argument:
"... if you are preparing a command line to give to `system(3)`"?
I first misread the above and thought you were doing some operation on the
result coming back from "system()", which of course is nonsensical and not
what you meant.
Thanks.
^ permalink raw reply
* Re: [PATCH 24/31] rebase: extract code for writing basic state
From: Thomas Rast @ 2011-01-04 19:19 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <1293528648-21873-25-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk wrote:
> Note that non-interactive rebase stores the sha1 of the original head
> in a file called orig-head, while interactive rebase stores it in a
> file called head.
[...]
> + if test "$type" = interactive
> + then
> + echo "$orig_head" > "$state_dir"/head
> + else
> + echo "$orig_head" > "$state_dir"/orig-head
> + fi &&
Do we have to cater to the use-case where the user starts a rebase,
downgrades at a conflict, and then continues?
If not, you could read 'orig-head' first and fall back to 'head', only
writing 'orig-head' in the state saving independent of the mode. That
would give us the chance of removing the redundancy at some point.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC PATCH 3/3] filter-branch: support --submodule-filter
From: Junio C Hamano @ 2011-01-04 19:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeffrey Phillips Freeman, git, Johannes Sixt, Jens Lehmann
In-Reply-To: <201101041414.19587.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Subject: TOY PATCH: filter-branch --split-submodule
>
> Sometimes it makes sense to split out a path not as a subdirectory
> (that would be merged by subtree-merge), but as a submodule. Since
> git objects are just shaped in the right way, this is actually quite
> easy to do in a way that maintains the correct history relations:
The patch from a cursory look feels sane.
> @@ -349,6 +352,43 @@ while read commit parents; do
> eval "$filter_index" < /dev/null ||
> die "index filter failed: $filter_index"
>
> + if test -n "$split_submodule"; then
> + sub_differs=
> + sub_parents=
> + sub_commit=
Just a style, but I find
if test -n "$split_submodule"
then
sub_differs= sub_parents= sub_commit=
easier to read. Not a biggie, as the neighbourhood in the script already
is infested in the other style, but I thought I'd mention it.
> + submodule="$(git rev-parse --verify $commit:$split_submodule 2>/dev/null)"
Do we need double quotes around it?
> + if test -z "$parents"; then
> + if test -n "$submodule"; then
> + sub_differs=t
> + fi
> + fi
if test -z "$parents" && test -n "$submodule"
then
sub_differs=t
fi
> + for parent in $parents; do
> + if ! test "$(git rev-parse --verify $parent:$split_submodule 2>/dev/null)" = "$submodule"; then
> + sub_differs=t
> + fi
If even one of the parents is different, we say "differs"...
> + if test -n "$sub_differs"; then
> + sub_commit="$(sed -e '1,/^$/d' <../commit |
> + git commit-tree $submodule $sub_parents)" || exit
> + else
> + for parent in $parents; do
> + sub_commit="$(git rev-parse --verify "$(map "$parent")":$split_submodule 2>/dev/null)"
> + break
... so we can just pick from the first parent and know all of them are the
same (could be empty which also is fine). Good.
^ permalink raw reply
* Re: [PATCH] daemon: support <directory> arguments again
From: Junio C Hamano @ 2011-01-04 19:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Erik Faye-Lund, git
In-Reply-To: <20110104040446.GA3541@burratino>
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation
From: Junio C Hamano @ 2011-01-04 19:18 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Drew Northup, git
In-Reply-To: <20110103190334.GA3767@gmx.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> ...
> As far as I can see, the only difference between my and your change is
> "burn" vs. "burning" (ignoring trailing white space). I don't see what
> your version is consistent to that mine isn't, but I think that yours
> is the grammatically correct way. I'm not a native speaker though.
> Anyway, here's the updated patch.
Thanks for your attention to the details. Will apply.
^ permalink raw reply
* Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules
From: Junio C Hamano @ 2011-01-04 19:17 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Marcin Wiśnicki
In-Reply-To: <1294147915-1475-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> 2011/1/4 Marcin Wiśnicki <mwisnicki@gmail.com>:
> > I think that for the time being at least the manual page must change to
> > reflect reality.
>
> Looks like changes will be more than just a few lines because path_matches()
> needs to learn about directories (iow less likely to get fixed right away).
> So, yes, good idea.
Not really. I'd rather see a handful of test cases added to t0003 to help
interested parties to see what is broken and what is not.
Quoting from Marcin's other message, assuming that "Patterns" are stored
in either .gitattributes at the top level or .git/info/attributes:
> Example for file: d1/d2/f1.c
>
> Patterns that match:
> *.c
No slashes, so it should match anywhere (correct).
> d1/d2/*
With slashes, so this is anchored at the toplevel of the working tree, and
the path should match (correct).
> /d1/d2/*
The same as above;, the leading '/' is only to make it explicit that it is
anchored at the level
> */d2/*
Should match.
> */*/*
Should match.
> Patterns that do not match but should:
> d2/*
This shouldn't match unless it appears in d1/.gitattributes.
The presense of '/' makes the pattern anchored to the directory it appear
in, and .git/info/attributes is taken as being at the top level.
> d2/
> d2
These shouldn't for the same reason.
> d1/d2
> /d1/d2
We somehow don't do leading path match like we do for gitignore, but I do
not think this was intended. My gut feeling is that these should match.
The thinking back, when we wrote the code, could have been that, unlike
gitignore that maintains only one bit (either "ignored" or "not"),
attributes are richer and giving the same attribute (say "whitespace
checking criteria") to files inside a directory and the containing
directory itself was nonsensical. But if that was the reason, it is
faulty, as we do not track directories anyway.
Wouldn't it be sufficient to teach attr.c:path_matches() that a pattern
could also match with leading path? That would automatically cover the
case where a pattern is terminated with a slash, as pattern "d/e/" would
never match path "d/e" but does match "d/e/f"?
^ permalink raw reply
* Re: [PATCH 08/31] rebase: align variable names
From: Thomas Rast @ 2011-01-04 19:12 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: git, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder
In-Reply-To: <1293528648-21873-9-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk wrote:
> Use the same names for variables that git-rebase--interactive.sh will
> soon inherit from git-rebase.sh.
AFAICS this is partly about spelling the variables in lowercase
instead of all-caps.
Wouldn't it be nicer to simply downcase *all* variables, so that the
end result has a consistent coding style?
> -# $UPSTREAM. They are not necessarily rewritten, but their children
> +# $upstream. They are not necessarily rewritten, but their children
[...]
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: developing a modified Linux-style workflow
From: Hans-Christoph Steiner @ 2011-01-04 19:01 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <E54235A96EB484418EBD9509F37176D210049C61@htmail10.hightouchinc.com>
On Dec 13, 2010, at 11:16 AM, Neal Kreitzinger wrote:
> "Hans-Christoph Steiner" <hans@at.or.at> wrote in message
> news:7EAE16CF-A9A8-47A6-9294-3646CCDB0E9C@at.or.at...
>>
>> Hey all,
>>
>> (and my second post on this list...)
>>
>> I've gotten pretty good at git, and its helping me already with
>> managing
>> the very odd workflows I have with the software I work a lot on
>> called Pd
>> (http://puredata.info). My role in Pd development is like a Linux
>> lieutenant.
>>
>> I also the main dev for an app called Pd-extended, which is based
>> on Pd.
>> Now I'm stuck trying to figure out how to use git to match my
>> current
>> workflow for Pd-extended, which is a kind of long-lived branch,
>> almost
>> like a friendly fork. So its kind of close to the Linux workflow
>> with me
>> as a lieutenant, but not quite.
>>
>> What makes it tricky is that I make releases directly from my repo
>> that
>> are widely used. So my repo is both lieutenant and dictator at
>> the same
>> time. So that's where I am stumped. I want to be able to rebase
>> and
>> push to a public repo, but that would be stupid. So there has got
>> to be
>> another way.
>>
>> .hc
>>
> I don't think pushing to a public repo is stupid. You could create
> a bare
> repo with a Pd branch and Pd-extended branch that contain the
> production
> versions of Pd and Pd-extended. The main reason our shop chose git is
> because it allows us to easily have multiple concurrent versions of
> production by having a branch for each of our custom versions. These
> versions eventually get merged together into a major release, but in
> the
> meantime they are longlived branches representing the productional
> customized system for each major customer.
>
> *If* you end up merging Pd and Pd-extended at some point, then you
> could
> have another branch for that, e.g. master or Pd-master or whatever.
> BTW,
> you do not have to use master as the representative of your final
> merged
> work so don't think that is the way you HAVE to do it. It's just the
> default, and a common practice for systems with a single version of
> production. Master can become vestigial or secondary, if you choose
> to
> create a new branch called Pd-master, etc. to represent your
> eventual merges
> of Pd and Pd-extended.
For me the biggest feature that I am looking for is the automatic
merging of commits, and second, having a branch that puts my
collection of patches/commits ahead of the Pd master so that its easy
to manage the patches. I don't think I see how I could do that with
this multiple branches idea. Is that possible?
.hc
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
^ permalink raw reply
* Re: gitattributes don't work
From: Junio C Hamano @ 2011-01-04 18:33 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <ifr610$3kl$1@dough.gmane.org>
Marcin Wiśnicki <mwisnicki@gmail.com> writes:
> I'm trying to exclude certain paths (those that contain "xmac/gen/") from
> diff output using .git/info/attributes (not .gitattributes).
>
> According to gitattributes(5) it supports patterns from gitignore(5).
>
> Example path that must be excluded:
> src/byucc/jhdl/CSRC/xmac/gen/and2_dp_g.xmac
>
> What I've tried but didn't work:
> xmac/gen/ -diff
Why not "xmac/gen/* -diff" or even "xmac/gen/*.xmac -diff"?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox