Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote: > So if you want a single boolean to toggle between the current > behaviour and the other one, it would be --post-order. But you may > at least want to consider pros and cons of allowing users to give > two separate commands, one for

Re: [PATCH v6] submodule: add 'deinit' command

Hi, On Mon, Mar 04, 2013 at 10:20:24PM +0100, Jens Lehmann wrote: > diff --git a/git-submodule.sh b/git-submodule.sh > index 004c034..44f70c4 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -547,6 +548,80 @@ cmd_init() > } > [...] > + > + module_list "$@" | > + while read m

Re: [PATCH] match_push_refs(): nobody sets src->peer_ref anymore

On Mon, Mar 04, 2013 at 02:36:33PM -0800, Junio C Hamano wrote: > In ancient times, we used to disallow the same source ref to be > pushed to more than one places, e.g. "git push there master:master > master:naster" was disallowed. We later lifted this restriction > with db27ee63929f (send-pack:

[PATCH] l10n: de.po: translate 1 new message

Translate 1 new message came from git.pot update in ed1ddaf (l10n: git.pot: v1.8.2 round 4 (1 changed)). Signed-off-by: Ralf Thielow --- po/de.po | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/po/de.po b/po/de.po index 37aa24d..83c30b1 100644 --- a/po/de.po +++ b/po/de.po

Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

git-submodule.sh: In foreach, make '-post-order' yield post-order traversal and '--include-super' execute commands at the top-level supermodule, with both of these options compatible with '--recursive'. Signed-off-by: Eric Cousineau --- Sorry about missing the part about not included MIME atta

Re: Fwd: Strange remote interaction

Javier Domingo writes: > I have just had the attached bash session, and I have no idea on what > is going on. > > Any help appreciated, > > Javier Domingo > > javier@frodo:~/proyectos/pfc$ git push -vvv javier master > Pushing to git@server:javier/pfc > To git@server:javier/pfc > ! [rejected]

Fwd: Git 1.8.2 l10n round 4

Hi, Leaders of Git language teams please note that a new "git.pot" is generated from v1.8.2-rc2-4-g77995 in the master branch. See commit: l10n: git.pot: v1.8.2 round 4 (1 changed) Generate po/git.pot from v1.8.2-rc2-4-g77995 for git v1.8.2 l10n round 4. Signed-off-by: Jiang Xin

[no subject]

binj2ENTGYfsu.bin Description: iso-8859-1

Re: rebase destroys branches

On Tue, Mar 05, 2013 at 02:05:32PM +1300, Gene Thomas [DATACOM] wrote: > > >The original branch is not 'destroyed', rather the pointer to the previous > >tip is within the logs. > > Is that the 'git log' log or internal logs? Are you sure? There doesn't > appear to be a way to checkout that ti

Fwd: Strange remote interaction

Hi, I have just had the attached bash session, and I have no idea on what is going on. Any help appreciated, Javier Domingo bug Description: Binary data

RE: rebase destroys branches

Philip, Thanks for your reply. >The original branch is not 'destroyed', rather the pointer to the previous tip >is within the logs. Is that the 'git log' log or internal logs? Are you sure? There doesn't appear to be a way to checkout that tip of see the log back from that tip. >All t

[PATCH 2/2] push: --follow-tag

The new option "--follow-tag" tells "git push" to push tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the comm

[PATCH 1/2] commit: add in_merge_bases_many()

Similar to in_merge_bases(commit, other) that returns true when commit is an ancestor (i.e. in the merge bases between the two) of the other commit, in_merge_bases_many(commit, n_other, other[]) checks if commit is an ancestor of any of the other[] commits. Signed-off-by: Junio C Hamano --- comm

git repo on Win 2008

What is the best way to host a shared git repo on a Windows 2008 box? I would like to create a repo on the 2008 box (that everyone will pull/push to), but add the initial code from my developer (Windows7 box). J.V. -- To unsubscribe from this list: send the line "unsubscribe git" in the body

Re: rebase destroys branches

From: "Gene Thomas [DATACOM]" Sent: Monday, March 04, 2013 11:06 PM Hello, I am evaluating git for use in a company. Please correct if I am wrong. I am concerned that an inexperienced developer could mistakenly rebase branches, destroying the original branch. The original branch is not 'destro

Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

Jens Lehmann writes: > Please don't attach your patches, see Documentation/SubmittingPatches on > how to post patches to this list. > > Am 04.03.2013 09:41, schrieb Eric Cousineau: >> In this patch, foreach --recursive acts depth-first, much like the default >> behavior described in the patch by

[PATCH] match_push_refs(): nobody sets src->peer_ref anymore

In ancient times, we used to disallow the same source ref to be pushed to more than one places, e.g. "git push there master:master master:naster" was disallowed. We later lifted this restriction with db27ee63929f (send-pack: allow the same source to be pushed more than once., 2005-08-06) and there

Re: Subtree in Git

On Sat, Mar 2, 2013 at 5:43 PM, Paul Campbell wrote: > On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr wrote: >> On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell wrote: >>> On Fri, Mar 1, 2013 at 2:28 AM, Kindjal wrote: David Michael Barr rr-dav.id.au> writes: > From a quick sur

Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

Please don't attach your patches, see Documentation/SubmittingPatches on how to post patches to this list. Am 04.03.2013 09:41, schrieb Eric Cousineau: > In this patch, foreach --recursive acts depth-first, much like the default > behavior described in the patch by Imram Yousuf in this > post

Re: "git rebase" loses the additional changes in "evil" merges

Thomas Rast writes: > Junio C Hamano writes: > >> wor...@alum.mit.edu (Dale R. Worley) writes: >> >>> (git version 1.7.7.6) >>> >>> I've been learning how to use Git. While exploring "git rebase", I've >>> discovered that if the branch being rebased contains an "evil" merge, >>> that is, a merg

Re: "git rebase" loses the additional changes in "evil" merges

Junio C Hamano writes: > wor...@alum.mit.edu (Dale R. Worley) writes: > >> (git version 1.7.7.6) >> >> I've been learning how to use Git. While exploring "git rebase", I've >> discovered that if the branch being rebased contains an "evil" merge, >> that is, a merge which contains changes that ar

[PATCH v6] submodule: add 'deinit' command

With "git submodule init" the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to "git submodule update". But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local w

Re: "git rebase" loses the additional changes in "evil" merges

wor...@alum.mit.edu (Dale R. Worley) writes: > (git version 1.7.7.6) > > I've been learning how to use Git. While exploring "git rebase", I've > discovered that if the branch being rebased contains an "evil" merge, > that is, a merge which contains changes that are in addition to the > changes in

Re: "git commit" fails due to spurious file in index

Robert Irelan writes: > Now, when I run 'git add admin_script/setup' to add the new directory to > the repo and then try to commit, I receive the following message: > > $ git commit > mv: cannot stat `admin_scripts/setup/2012/setup': No such file or > directory > > The error message is c

"git rebase" loses the additional changes in "evil" merges

(git version 1.7.7.6) I've been learning how to use Git. While exploring "git rebase", I've discovered that if the branch being rebased contains an "evil" merge, that is, a merge which contains changes that are in addition to the changes in any of the parent commits, the rebase operation will sil

Re: [PATCH] Allow combined diff to ignore white-spaces

On Mon, Mar 4, 2013 at 7:36 PM, Junio C Hamano wrote: > Antoine Pelisse writes: > >> It feels incorrect to me to coalsesce "- 5" and "- 5" as it might >> look incorrect to the user. But still the idea is appealing. > > The users already need to see that when reading a regular patch with > one or

Re: [BUG/TEST 0/2] bugs with cherry-pick renames

On 02/11/13 20:27, Stephen Boyd wrote: > I ran into these bugs the other day and didn't have time to > investigate further. So I wrote test cases for them instead. > > Stephen Boyd (2): > t3501: Expose bug with cherry-pick into dirty trees w/ renames > t3501: Expose addinfo_cache error message

Re: [PATCH] Allow combined diff to ignore white-spaces

Antoine Pelisse writes: > It feels incorrect to me to coalsesce "- 5" and "- 5" as it might > look incorrect to the user. But still the idea is appealing. The users already need to see that when reading a regular patch with one or more context lines and -b/-w/etc., anyway. The context lines ar

"git commit" fails due to spurious file in index

Hello all: This is my first time posting to this mailing list, but it appears to me, through a Google search, that this is where you go to report what might be bugs. I'm not sure if this is a bug or not, but it is mysterious to me. My git repository has this directory structure (I don't know if t

Re: [PATCH] Allow combined diff to ignore white-spaces

>> That should be reviewed carefully as I'm not exactly sure that does make >> sense with the way combined-diff works. >> Still it seems natural to me to be able to remove the space in combined >> diff as we do with normal diff. Especially as I unfortunately have to >> deal with many space + featur

Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached

Duy Nguyen writes: >> Instead of punting to "Currently not on any branch", would it help >> to show the place you first detached at, so that the user can then >> grab that commit object name and run >> >> $ git log --oneline $that_commit.. >> >> or something? > > $that_commit would be HEAD@{-

Re: Configurable .gitignore filename?

2013/3/4 Matthieu Moy : > There is already core.excludesfile, which does not replace the usual > .gitignore but comes in addition. The common use is a user-wide ignore > file, not a per-directory one. I'm actually aware of that. Problem is the normal .gitignore files must *not* be used in the seco

Re: Configurable .gitignore filename?

Jari Pennanen writes: > If project or directory belongs to more than one GIT_DIR then some of > the GIT_DIR's may need a different .gitignore files, it would be > useful if one could define it independently, e.g. in GIT_DIR/config: > > [core] > ignorefilename = .gitalternateignore There is alrea

Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached

On Mon, Mar 4, 2013 at 5:25 AM, Junio C Hamano wrote: >> When a remote ref or a tag is checked out, HEAD is automatically >> detached. There is no user friendly way to find out what ref is >> checked out in this case. This patch digs in reflog for this >> information and shows "Detached from origi

Configurable .gitignore filename?

If project or directory belongs to more than one GIT_DIR then some of the GIT_DIR's may need a different .gitignore files, it would be useful if one could define it independently, e.g. in GIT_DIR/config: [core] ignorefilename = .gitalternateignore Has anyone considered making the .gitignore filen

Re: git-p4: Importing a Git repository into Perforce without rebasing

Hi, perhaps you should give Perfoce's git-bridge a try. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Mobile: +49 (151) 27565287 Fax: +49 (30) 3464615-59 enri

Re: [PATCH] Avoid loading commits twice in log with diffs

Junio C Hamano writes: > Thomas Rast writes: > >> Test with patchbefore >> >> 4000.2: log --raw -3000 0.50(0.43+0.06) 0.54(0.46+0.06) +7.0%*** >> 4000.3: log -p -3000 2.34(2.20+0.13) 2.37

Re: [RFC v2] git-multimail: a replacement for post-receive-email

Matthieu Moy writes: > A few more random thoughts (not on my personal todo-list): One more: When sending commit emails, it may help to ensure that the dates are strictly monotonic, so that the thread is seen in the right order. IIRC, "git send-email" does this by tweaking the Date: field to ma

rosellevalent...@gmail.com

Sent from my iPad Roselle Lee Valentino -- 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

[PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

In this patch, foreach --recursive acts depth-first, much like the default behavior described in the patch by Imram Yousuf in this post . Changes were made so that the submodule "Entering ..." message was right next to the output generated by the comma