* Re: Branch dependencies
From: Bert Wesarg @ 2011-08-02 23:25 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis
In-Reply-To: <20110802190806.GA16674@fishbowl.rw.madduck.net>
Hi,
On Tue, Aug 2, 2011 at 21:08, martin f krafft <madduck@madduck.net> wrote:
> also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2011.08.02.1506 +0200]:
>> while I appreciate, that you dig this topic up. I think you are trying
>> to solve the wrong problem first. My main problem with the TopGit
>> approach is, that you can't freely change the dependencies of a topic.
>> This may be not the most common case in distro development. But in my
>> eyes more problematic than maintaining the meta data.
>
> Hello Bert, thank you for taking the time to respond!
>
> Could you please try to illuminate me a bit on a use-case of
> changing dependencies? I am aware that TopGit has had a problem with
> changing dependencies due to renamed branches, and I think I have
> a solution to that (encode the dependent ref, not the branch head),
> but I cannot come up with a use case for freely changing
> dependencies just like that.
Not each feature branch may end up in master. And there does not need
to be one feature branch which depends on all other features. For the
latter you have probably an empty feature branch which just depends on
all features. I call this branch mostly 'tip'. Removing a feature
branch from the tips dependency list only with merges can't be done
right now, and the proposed solutions never reached a usable state.
My second usecase is to convert a big quilt patch series into TopGit.
Such big Quilt patches have mostly an artificial dependency to its
predecessors. Removing these artifical dependencies makes it necessary
to remove dependencies from patches.
>
>> For my first mentioned problem, I think a new 'system' needs to be
>> 'rebase' based, not merge based like TopGit.
>
> The problem with rebasing is that you cannot publish the branches.
That doesn't hold you back to publish them. But the other side need to
know how to deal with them.
Saying that doesn't mean I know a good way to deal with them. I mostly
end up using plumbing commands to deal with this.
>
> However, maybe I am simply not seeing the light here. Do you have
> some further ideas about what this would be like? Please keep in
> mind that what I seek is not just a way to bring feature branches
> up-to-date with upstream, but also to have those branches be shared
> among developers.
I think that having the TopGit philosophy of one feature branch is one
patch, you can handle an rebased upstream. Thinking of a feature
branch as a series of patches makes this way harder. But I would like
to have this philosophy.
Bert
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Johannes Sixt @ 2011-08-02 23:37 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <20110802181357.GA1861@sigill.intra.peff.net>
Am 02.08.2011 20:13, schrieb Jeff King:
> Hmm. So it's not _just_ the pipe vs file thing. What's different about
> calling it from the shell, versus the way we call it from git-archive?
When the parent process of an MSYS process is itself an MSYS process,
such as bash, then the child does not do its own
binary-mode-vs.-text-mode detection, but just uses whatever it is told
by the parent. This is achieved by MSYS's fork emulation.
But if the parent is a regular Windows program, such as git(-archive),
then the autodection happens and file descriptors pointing to files are
put into text mode.
-- Hannes
^ permalink raw reply
* repeatedly conflicting files when using git svn rebase
From: Mike Gant @ 2011-08-03 0:41 UTC (permalink / raw)
To: git
All,
I have a problem where every time I run 'git svn rebase', I have the
same files with conflicts. Not only that but when I fix the conflict,
there is no change to add and I end up having to do 'git rebase --skip'.
Some of the differences are only whitespace but all are minor changes.
I've tried choosing the other part of the conflict (so I end up using
'git rebase --continue') but I still have the conflicts the next time I
run 'git svn rebase' . I should also note that this happens _everytime_
I run 'git svn rebase' even consecutive times with absolutely no other
operations in between. Does anyone have any suggestions?
(Unfortunately, I cannot share the repo.)
Thanks,
Mike
^ permalink raw reply
* Re: [RFC/ PATCH] revert: Allow arbitrary sequencer instructions
From: Ramkumar Ramachandra @ 2011-08-03 1:32 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110802205353.GF2743@elie>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> --- a/sequencer.h
>> +++ b/sequencer.h
>> @@ -32,6 +32,16 @@ struct replay_opts {
>> size_t xopts_nr, xopts_alloc;
>> };
>>
>> +struct replay_insn {
>> + struct commit *commit;
>> + enum replay_action action;
>> +};
>> +
>> +struct replay_insn_list {
>> + struct replay_insn *item;
>> + struct replay_insn_list *next;
>> +};
>
> Ah, so this allows sequences like
>
> revert A
> pick B
> pick C
> revert D
Exactly.
> Nit: why isn't the list-item struct something like
>
> struct replay_insn item;
> struct replay_insn_list *next;
>
> which would save a little memory management and memory access
> overhead (or even
>
> enum replay_action action;
> struct commit *operand;
> struct replay_insn_list *next;
>
> since every "struct replay_insn" exists in the context of an
> insn list afaict)?
Right. Good suggestion.
> Anyway, the general idea seems good.
Nice. Thanks for the quick early feedback. Much appreciated.
-- Ram
^ permalink raw reply
* [PATCH] Add option hooks.emaildiff to include full diff in post-receive-email
From: Jon Jensen @ 2011-08-03 3:34 UTC (permalink / raw)
To: git
I've always found that a very important part of receiving email
notification of commits is being able to read the diff inline,
easily, where I can reply and quote the diff and make comments.
It's similar to the reason patches sent to the Git mailing list
need to be inline, not attachments.
Since post-receive-email didn't have that option, this adds it as a
boolean config variable, hooks.emaildiff.
Signed-off-by: Jon Jensen <jon@endpoint.com>
---
contrib/hooks/post-receive-email | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 21989fc..5b9b26d 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -60,6 +60,9 @@
# email body. If not specified, there is no limit.
# Lines beyond the limit are suppressed and counted, and a final
# line is added indicating the number of suppressed lines.
+# hooks.emaildiff
+# If set, then a full diff of changes is sent in addition to the default
+# summary output.
#
# Notes
# -----
@@ -445,8 +448,13 @@ generate_update_branch_email()
# - including the undoing of previous revisions in the case of
# non-fast-forward updates.
echo ""
- echo "Summary of changes:"
- git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
+ if [ -n "$emaildiff" ]; then
+ echo "Summary of changes and diff:"
+ git diff-tree --stat --summary --find-copies-harder -p $oldrev..$newrev
+ else
+ echo "Summary of changes:"
+ git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
+ fi
}
#
@@ -723,6 +731,7 @@ envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
custom_showrev=$(git config hooks.showrev)
maxlines=$(git config hooks.emailmaxlines)
+emaildiff=$(git config hooks.emaildiff)
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.7.6.233.gd79bc
^ permalink raw reply related
* [PATCH] Mark post-receive-email with Precedence: list to avoid autoresponder replies
From: Jon Jensen @ 2011-08-03 3:35 UTC (permalink / raw)
To: git
Signed-off-by: Jon Jensen <jon@endpoint.com>
---
contrib/hooks/post-receive-email | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 5b9b26d..c5b1891 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -236,6 +236,7 @@ generate_email_header()
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
X-Git-Newrev: $newrev
+ Precedence: list
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
--
1.7.6.233.gd79bc
^ permalink raw reply related
* Re: [PATCH v14 8/8] bisect: change bisect function to update BISECT_HEAD, rather than HEAD.
From: Christian Couder @ 2011-08-03 4:43 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, j6t, jnareb
In-Reply-To: <1312323362-20096-9-git-send-email-jon.seymour@gmail.com>
I think a better title for this patch would be something like:
bisect: update BISECT_HEAD, rather than HEAD, when using --no-checkout
But anyway in my opinion the patch series would be better if this patch was
squashed into the previous patches.
On Wednesday 03 August 2011 00:16:02 Jon Seymour wrote:
> This function modifies git-bisect so that the --no-checkout option
> uses BISECT_HEAD rather than HEAD to record the current bisection
> head.
s/This function/This patch/
> The intent is to reduce the confusion that uses of --no-checkout
s/uses/users/
> may experience when using the --no-checkout option since the bisection
> process will no longer introduce spurious differences between the
> HEAD reference and the working tree and index.
>
> Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
> ---
> Documentation/git-bisect.txt | 8 ++++----
> bisect.c | 2 +-
> builtin/bisect--helper.c | 2 +-
> git-bisect.sh | 17 +++++++++++++----
> t/t6030-bisect-porcelain.sh | 30 +++++++++++++++---------------
> 5 files changed, 34 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 2014894..a9b217b 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -267,9 +267,9 @@ OPTIONS
> -------
> --no-checkout::
> +
> -This option is used to specify that 'git bisect' should not modify the
> working -tree or index on each iteration of the bisection process but
> should -update HEAD instead.
> +This option is used to specify that 'git bisect' should not checkout the
> +new working tree at each iteration of the bisection process but should
> +instead update BISECT_HEAD.
I would say something like:
Do not checkout the new working tree at each iteration of the bisection
process. Instead just update a special reference named 'BISECT_HEAD' to make
it point to the commit that should be tested.
> +
> This option is useful in circumstances in which checkout is either not
> possible (because of a damaged respository) or is otherwise not required.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 5:17 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, j6t, jnareb
In-Reply-To: <1312323362-20096-6-git-send-email-jon.seymour@gmail.com>
On Wednesday 03 August 2011 00:15:59 Jon Seymour wrote:
> @@ -291,7 +304,7 @@ bisect_next() {
> bisect_next_check good
>
> # Perform all bisection computation, display and checkout
> - git bisect--helper --next-all
> + git bisect--helper --next-all ${BISECT_MODE}
Style, please use $BISECT_MODE instead of ${BISECT_MODE}
Thanks,
Christian.
^ permalink raw reply
* [PATCH 1bis/2] Diff patterns for POSIX shells
From: Giuseppe Bilotta @ 2011-08-03 5:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <7vzkjrem6b.fsf@alter.siamese.dyndns.org>
All diffs following a function definition will have that function name
as chunck header, but this is the best we can do with the current
userdiff capabilities.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
userdiff.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/userdiff.c b/userdiff.c
index 01d3a8b..94b1c47 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -107,6 +107,9 @@
"(@|@@|\\$)?[a-zA-Z_][a-zA-Z0-9_]*"
"|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+|\\?(\\\\C-)?(\\\\M-)?."
"|//=?|[-+*/<>%&^|=!]=|<<=?|>>=?|===|\\.{1,3}|::|[!=]~"),
+PATTERNS("shell", "^[ \t]*([a-zA-Z_0-9]+)[ \t]*\\(\\).*",
+ /* -- */
+ "\\$?[a-zA-Z_0-9]+|&&|\\|\\|"),
PATTERNS("bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
"[={}\"]|[^={}\" \t]+"),
PATTERNS("tex", "^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
--
1.7.6.485.gd947c.dirty
^ permalink raw reply related
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 5:27 UTC (permalink / raw)
To: Jon Seymour; +Cc: Christian Couder, git, gitster, j6t, jnareb
In-Reply-To: <CAH3AnrrkAeN3BgnnFBsbzh=37tC6f6aRACgk94wxW85qFQpfVw@mail.gmail.com>
On Tuesday 02 August 2011 16:41:13 Jon Seymour wrote:
> On Tue, Aug 2, 2011 at 10:04 PM, Christian Couder
>
> <christian.couder@gmail.com> wrote:
> > On Tue, Aug 2, 2011 at 1:29 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> >> @@ -34,6 +34,8 @@ require_work_tree
> >> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
> >> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
> >>
> >> +BISECT_MODE=$(test -f "$GIT_DIR/BISECT_MODE" && cat
> >> "$GIT_DIR/BISECT_MODE")
> >
> > Could you put this line just where it is needed, that is in
> > bisect_next() and bisect_reset()?
>
> Ultimately, it is also needed in paths that call bisect_state(), such
> as bisect_run() and bisect_skip() so I am not keen to do this.
>
> If I was to do this, I'd prefer to change uses of $BISECT_MODE with a
> call to a function bisect_mode() that does the same thing.
Yeah, I think it would be a good idea to have a bisect_mode() function.
I don't like very much to blindly call some code when we might not need it.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Seymour, git, j6t, jnareb
In-Reply-To: <7vk4avcsk9.fsf@alter.siamese.dyndns.org>
On Wednesday 03 August 2011 01:16:54 Junio C Hamano wrote:
>
> Having said that, other than these minor nits, I think this round is
> almost ready. I didn't check how it behaves upon "bisect reset",
> though. It shouldn't touch the index, HEAD nor the working tree (it
> probably is just the matter of "update-ref -d BISECT_HEAD" and nothing
> else, but I haven't thought things through thoroughly).
>
> Further polishing we may want to do while it is still in pu/next I can
> think of off the top of my head are:
>
> - In this mode, I can bisect the history even inside a bare repository,
> as the whole point of --no-checkout is that the mode does not require a
> working tree. I however suspect "git bisect" requires working tree. Is
> this something we want to fix?
>
> - Further, perhaps should we default to this mode inside a bare
> repository?
I agree that it would be nice if it worked in a bare repo. I did not look at
that yet.
> Christian, do you think of anything else?
No, I agree that it looks almost ready.
The few improvements I would like are:
- squashing the last patch into the previous ones,
- using a bisect_mode() function when needed.
> Also do you see flaws in our
> reasoning that updating only BISECT_HEAD and doing nothing else is a good
> way to do this?
No, I agree that --no-checkout is a good idea and that using only BISECT_HEAD
is good way to do this.
Thanks,
Christian.
^ permalink raw reply
* Re: Why do some commits not appear in "git log"?
From: Dov Grobgeld @ 2011-08-03 5:47 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <CAMOZ1Bt+Z4XDPNBQyUeVk30aEOuXFAuh8jhdhFke-CDZt2pEDg@mail.gmail.com>
--full-history indeed made the missing commits show up! So why was the
commit pruned? It contains some substantial source changes as may be
seen by the following commands:
1. Commit history for entire project:
> git log --full-history --pretty=oneline -5 --abbrev-commit | ~/scripts/crop
e86d3b1 Merge remote-tracking ...
05e7103 Made the system conver...
2de7375 Fixed compilation unde...
b520873 Error handling!!
73110bd New Group manager for ...
2. Diff of a single file between two commits show that 05e7103
contains a substantial change for the file.
> git diff 05e7103 2de7375 Apps/SolarJet/Project/qt/SysScripts/init.py | wc
105 389 5336
3. Full history of the file includes 05e7103
> git log --full-history --pretty=oneline -5 --abbrev-commit Apps/SolarJet/Project/qt/SysScripts/init.py | ~/scripts/crop
05e7103 Made the system conver...
84a60b7 avoid CarouselSimulati...
c40df74 git-svn-id: svn://swte...
0bdf4b6 Group manager for mult...
0536a0d git-svn-id: svn://swte...
4. But the default "pruned" history of the file does not contain 05e7103
> git log --pretty=oneline -5 --abbrev-commit Apps/SolarJet/Project/qt/SysScripts/init.py | ~/scripts/crop
84a60b7 avoid CarouselSimulati...
c40df74 git-svn-id: svn://swte...
0536a0d git-svn-id: svn://swte...
a720b61 Add full line wafer pr...
08b366b git-svn-id: svn://swte...
5. Here is the project graph:
> git log --graph --abbrev-commit --pretty=oneline -20 | ~/scripts/crop
* e86d3b1 Merge remote-track...
|\
| * 026fec8 Stop all the jobs ...
| * 84a60b7 avoid CarouselSimu...
| * c40df74 git-svn-id: svn://...
| * fee6808 git-svn-id: svn://...
| * 047e697 Automatic Theta Ca...
* | 05e7103 Made the system co...
* | 2de7375 Fixed compilation ...
* | b520873 Error handling!!
* | 73110bd New Group manager ...
* | dce3ae9 Merge branch 'Mu...
|\ \
| * \ 25dff3c Merge branch '...
Finally, a few more questions. Is it possible to make gitk use the
--full-history option when running 'gitk file'? Is there any
configuration flag that always turns on "full history"?
Thanks!
Dov
On Tue, Aug 2, 2011 at 18:56, Michael Witten <mfwitten@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 15:38, Dov Grobgeld <dov.grobgeld@gmail.com> wrote:
>> git log --pretty=oneline --abbrev-commit | head -20
>
> Try `--full-history' maybe? Also, rather than `head -20', you can
> limit the output directly with `-20':
>
> git log --pretty=oneline --abbrev-commit --full-history -20
>
> It's hard to know what's going on in your particular example; perhaps
> give us the output of `git log' when using the `--graph' option.
>
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-08-03 5:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: René Scharfe, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <4E388A55.6080606@kdbg.org>
On Wed, Aug 03, 2011 at 01:37:57AM +0200, Johannes Sixt wrote:
> Am 02.08.2011 20:13, schrieb Jeff King:
> > Hmm. So it's not _just_ the pipe vs file thing. What's different about
> > calling it from the shell, versus the way we call it from git-archive?
>
> When the parent process of an MSYS process is itself an MSYS process,
> such as bash, then the child does not do its own
> binary-mode-vs.-text-mode detection, but just uses whatever it is told
> by the parent. This is achieved by MSYS's fork emulation.
>
> But if the parent is a regular Windows program, such as git(-archive),
> then the autodection happens and file descriptors pointing to files are
> put into text mode.
Yuck. Well, I guess that's not really an option, then. The pipe trick
sounds like the sanest option (it would even be trivial to switch the
default value to "gzip -cn | cat" on Windows, but I assume "cat" has the
same problem).
Thanks for the explanation.
-Peff
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Heiko Voigt @ 2011-08-03 6:25 UTC (permalink / raw)
To: Jens Lehmann
Cc: henri GEIST, Alexei Sholik, Junio C Hamano, git, Sverre Rabbelier
In-Reply-To: <4E384510.1070803@web.de>
Hi Henri,
On Tue, Aug 02, 2011 at 08:42:24PM +0200, Jens Lehmann wrote:
> Am 02.08.2011 14:19, schrieb henri GEIST:
> > Le lundi 01 ao??t 2011 ?? 21:39 +0200, Jens Lehmann a ??crit :
> >> Am 30.07.2011 23:55, schrieb henri GEIST:
> >>> I can not see the difference with a gitlink.
> >>
> >> Then you can just use a config file for that, no? ;-)
> >
> > Off corse, I immediately start to work on it.
>
> I'm looking forward to that!
Before hacking away please share some design information about this.
Another thing:
It sounds like the workflow you want to achieve is similar to the one
the android developers are using. They have a lot of submodules which
need automatic updating.
The last time I checked they used repo (similar tool to submodules)
together with gerrit.
AFAIR they wanted to switch to submodules and have gerrit automatically
make the superproject commits for single submodule changes. Additionally
if a change involves multiple submodules the developer should be able to
tie them together using a superproject commit.
Have a look over there whether that workflow might help you?
Cheers Heiko
^ permalink raw reply
* [PATCH rc/histogram-diff] Make test number unique
From: Johannes Sixt @ 2011-08-03 7:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Tay Ray Chuan
From: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
...9-diff-histogram.sh => t4050-diff-histogram.sh} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t4049-diff-histogram.sh => t4050-diff-histogram.sh} (100%)
diff --git a/t/t4049-diff-histogram.sh b/t/t4050-diff-histogram.sh
similarity index 100%
rename from t/t4049-diff-histogram.sh
rename to t/t4050-diff-histogram.sh
--
1.7.6.1571.g6e29e
^ permalink raw reply
* [PATCH] Skip archive --remote tests on Windows
From: Johannes Sixt @ 2011-08-03 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git Mailing List, Erik Faye-Lund
From: Johannes Sixt <j6t@kdbg.org>
These depend on a working git-upload-archive, which is broken on Windows,
because it depends on fork().
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
These prerequisites are needed in current master, but would have to be
patched out again by Erik's upload-archive series.
t/t5000-tar-tree.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 9e3ba98..d906898 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -266,7 +266,7 @@ test_expect_success 'archive --list mentions user filter' '
grep "^bar\$" output
'
-test_expect_success 'archive --list shows only enabled remote filters' '
+test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
git archive --list --remote=. >output &&
! grep "^tar\.foo\$" output &&
grep "^bar\$" output
@@ -298,7 +298,7 @@ test_expect_success 'extension matching requires dot' '
test_cmp b.tar config-implicittar.foo
'
-test_expect_success 'only enabled filters are available remotely' '
+test_expect_success NOT_MINGW 'only enabled filters are available remotely' '
test_must_fail git archive --remote=. --format=tar.foo HEAD \
>remote.tar.foo &&
git archive --remote=. --format=bar >remote.bar HEAD &&
@@ -341,12 +341,12 @@ test_expect_success GZIP,GUNZIP 'extract tgz file' '
test_cmp b.tar j.tar
'
-test_expect_success GZIP 'remote tar.gz is allowed by default' '
+test_expect_success GZIP,NOT_MINGW 'remote tar.gz is allowed by default' '
git archive --remote=. --format=tar.gz HEAD >remote.tar.gz &&
test_cmp j.tgz remote.tar.gz
'
-test_expect_success GZIP 'remote tar.gz can be disabled' '
+test_expect_success GZIP,NOT_MINGW 'remote tar.gz can be disabled' '
git config tar.tar.gz.remote false &&
test_must_fail git archive --remote=. --format=tar.gz HEAD \
>remote.tar.gz
--
1.7.6.1572.g1f80c3
^ permalink raw reply related
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 9:07 UTC (permalink / raw)
To: PJ Weisberg
Cc: Heiko Voigt, Jens Lehmann, Alexei Sholik, Junio C Hamano,
git@vger.kernel.org, Sverre Rabbelier
In-Reply-To: <CAJsNXT=93FHjbi42JKA3Pg7PGXs0kEONJ5AC5SSPpa5RSVqB=A@mail.gmail.com>
Le mardi 02 août 2011 à 12:19 -0700, PJ Weisberg a écrit :
> On Tuesday, August 2, 2011, henri GEIST
> <henri.geist@flying-robots.com> wrote:
> > Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :
> >> Adding the ability to point to git repositories outside of the
> worktree
> >> does not solve anything but rather creates more problems. Resolving
> such
> >> dependencies can not be achieved if only A knows that it needs
> version X
> >> and only B knows that it needs version Y.
> >>
> >
> > Why not it work perfect for me and for debian as well.
>
> In the Debian analogy: A knows that it needs version X, B knows that
> it needs version Y, but A does not know that if it installs version X,
> B will break. That's the job of the superproject (Aptitude).
>
Your right.
^ permalink raw reply
* Re: [PATCH] Skip archive --remote tests on Windows
From: Jakub Narebski @ 2011-08-03 9:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Jeff King, Git Mailing List, Erik Faye-Lund
In-Reply-To: <4E3904B8.7080208@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> These depend on a working git-upload-archive, which is broken on Windows,
> because it depends on fork().
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> These prerequisites are needed in current master, but would have to be
> patched out again by Erik's upload-archive series.
[...]
> -test_expect_success 'archive --list shows only enabled remote filters' '
> +test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
Shouldn't the prerequisite be called FORK rather than NON_MINGW?
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 1bis/2] Diff patterns for POSIX shells
From: Jeff King @ 2011-08-03 9:32 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1312349176-20984-1-git-send-email-giuseppe.bilotta@gmail.com>
On Wed, Aug 03, 2011 at 07:26:16AM +0200, Giuseppe Bilotta wrote:
> All diffs following a function definition will have that function name
> as chunck header, but this is the best we can do with the current
> userdiff capabilities.
Curious as to how this would look in git.git, I tried "git log -p"
before and after your patches, and diffed the result. I noticed two
things:
1. Given a block of shell code like this:
foo() {
... do something ...
}
test_expect_success 'test foo' '
... the actual test ...
'
if we add new code after the test, the old regex would print:
@@ -1,2 +3,4 @@ test_expect_success 'test foo' '
and now we say:
@@ -1,2 +3,4 @@ foo
which seems more misleading. I know the function-matching code has
no way to say "look for ^}, which signals end of function", so we
can't be entirely accurate. But I wonder if the new heuristic
(which seems to look for a name followed by parentheses) is
actually any better than the old.
2. What would have printed before:
@@ -1,2 +3,4 @@ foo() {
now prints
@@ -1,2 +3,4 @@ foo
without the parentheses or brace. It looks like the similar C one
keeps the parentheses, at least. I find that a bit more readable,
as it is more clear that the line indicates a function, and not
simply some top-level command.
-Peff
^ permalink raw reply
* [PATCH] am: pass exclude down to apply
From: maximilian attems @ 2011-08-03 9:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, maximilian attems
This allows to pass patches around from repositories,
where the other repository doesn't feature certain files.
In the special case this works for dash git sync to klibc dash:
git am --directory="usr/dash" --exclude="usr/dash/configure.ac" \
--exclude="usr/dash/ChangeLog" --exclude="usr/dash/dash.1" \
.. -i -s -k ../dash/000X-foo.patch
Signed-off-by: maximilian attems <max@stro.at>
---
git-am.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
This is a resent, haven't a test for this usecase,
but it is useful and simple enough, so reposted.
diff --git a/git-am.sh b/git-am.sh
index 463c741..8d185aa 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,6 +22,7 @@ whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
directory= pass it through git-apply
+exclude= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
patch-format= format the patch(es) are in
@@ -366,7 +367,7 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace|--directory)
+ --whitespace|--directory|--exclude)
git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--
1.7.5.4
^ permalink raw reply related
* changing the set of dependencies (was: Branch dependencies)
From: martin f krafft @ 2011-08-03 9:51 UTC (permalink / raw)
To: Bert Wesarg, git discussion list, Petr Baudis
In-Reply-To: <CAKPyHN0EsXMKQ2g7ONaO4yw2ioPbMhg8XCsmB20je=O1DDeE5Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2011.08.03.0125 +0200]:
> Not each feature branch may end up in master. And there does not need
> to be one feature branch which depends on all other features. For the
> latter you have probably an empty feature branch which just depends on
> all features. I call this branch mostly 'tip'. Removing a feature
> branch from the tips dependency list only with merges can't be done
> right now, and the proposed solutions never reached a usable state.
>
> My second usecase is to convert a big quilt patch series into TopGit.
> Such big Quilt patches have mostly an artificial dependency to its
> predecessors. Removing these artifical dependencies makes it necessary
> to remove dependencies from patches.
Dear Bert, thank you for your reply.
Okay, understood. Yes, I agree entirely, the set of dependencies
needs to be mutable. And they must not be invalidated by branch
renames. Therefore, we really need some sort of other way to
identify branches.
Is there a way other than lamenting that refs did not get UUIDs
assigned to them from the early days onwards? ;)
--
martin | http://madduck.net/ | http://two.sentenc.es/
"if one cannot enjoy reading a book over and over again,
there is no use in reading it at all."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* TopGit with rebased branches, problems with publishing (was: Branch dependencies)
From: martin f krafft @ 2011-08-03 10:01 UTC (permalink / raw)
To: Bert Wesarg, git discussion list, Petr Baudis
In-Reply-To: <CAKPyHN0EsXMKQ2g7ONaO4yw2ioPbMhg8XCsmB20je=O1DDeE5Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2011.08.03.0125 +0200]:
> >> For my first mentioned problem, I think a new 'system' needs to be
> >> 'rebase' based, not merge based like TopGit.
> >
> > The problem with rebasing is that you cannot publish the branches.
>
> That doesn't hold you back to publish them. But the other side need to
> know how to deal with them.
>
> Saying that doesn't mean I know a good way to deal with them. I mostly
> end up using plumbing commands to deal with this.
Let me address this in terms of patch queue branches. Obviously, you
are talking topic branches, but wrt rebase-publish, the two are
identical. Patch queue branches are essentially quilt imports, e.g.
one-commit-one-patch, usually edited with git rebase -i (which some
people consider to be the better quilt).
The problem that led me away from patch queue branches is that
— albeit unlikely in our context (distro packaging) — it is possible
that you and I both rewrite the patch queue at the same time. The
first one to push will then have his changes overwritten by the
second push — in order to push the rebased ref,
receive.denyNonFastForwards needs to be off.
Unfortunately, I can't see a remedy to this, apart from tagging each
and every patch queue branch, but that does not solve the problem of
having to merge changes made simultaneously. It could go something
like this:
1. ensure that noone has pushed an updated ref since you last
fetched.
2. if a new ref is found, download it and rebase your own patch
queue on top of it, consolidating the changes.
3. tag and push your new ref.
But there's a race condition in this, and so we're back to square
one.
--
martin | http://madduck.net/ | http://two.sentenc.es/
uʍop ǝpısdn sı ɹoʇıuoɯ ɹnoʎ
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Tracking topic branches with rebases vs. merges (was: Branch dependencies)
From: martin f krafft @ 2011-08-03 10:10 UTC (permalink / raw)
To: Bert Wesarg, git discussion list, Petr Baudis
In-Reply-To: <CAKPyHN0EsXMKQ2g7ONaO4yw2ioPbMhg8XCsmB20je=O1DDeE5Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2011.08.03.0125 +0200]:
> I think that having the TopGit philosophy of one feature branch is
> one patch, you can handle an rebased upstream. Thinking of
> a feature branch as a series of patches makes this way harder. But
> I would like to have this philosophy.
Let me just make sure I understand you right: you do not like the
following branch management strategy:
o--o--o--+--o--o--+--o-.
/ / / \
o--o--o--o--o--o--o--o--o--o--o--●
and you would prefer if the topic branch was rebased all along (like
what git.git advocates), and then transferred to mainline with
git-format-patch/git-send-e-mail/git-am (or ff-merged).
I am torn on this issue. On the one hand, I do not find the above to
be so problematic, especially not if the downstream merges happen
only infrequently (undo merges that do not produce conflicts, as
advocated by gitworkflows(7)).
On the other hand, I completely agree with you that rebasing is much
nicer, and it certainly works without publishing the branch. In
git.git, people seem to maintain their own branches and send patch
sets to the mailing list for review.
But how could you and I truly cooperate on a feature branch without
using merges, and without establishing a lock-unlock protocol to
ensure only sequential updates of the refs?
Thanks,
--
martin | http://madduck.net/ | http://two.sentenc.es/
"alles gackert, aber wer will noch still
auf dem nest sitzen und eier zu brüten?"
-- friedrich wilhelm nietzsche
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Re: [PATCH 1bis/2] Diff patterns for POSIX shells
From: Giuseppe Bilotta @ 2011-08-03 10:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20110803093252.GA16351@sigill.intra.peff.net>
On Wed, Aug 3, 2011 at 11:32 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 03, 2011 at 07:26:16AM +0200, Giuseppe Bilotta wrote:
>
>> All diffs following a function definition will have that function name
>> as chunck header, but this is the best we can do with the current
>> userdiff capabilities.
>
> Curious as to how this would look in git.git, I tried "git log -p"
> before and after your patches, and diffed the result. I noticed two
> things:
>
> 1. Given a block of shell code like this:
>
> foo() {
> ... do something ...
> }
>
> test_expect_success 'test foo' '
> ... the actual test ...
> '
>
> if we add new code after the test, the old regex would print:
>
> @@ -1,2 +3,4 @@ test_expect_success 'test foo' '
>
> and now we say:
>
> @@ -1,2 +3,4 @@ foo
>
> which seems more misleading. I know the function-matching code has
> no way to say "look for ^}, which signals end of function", so we
> can't be entirely accurate. But I wonder if the new heuristic
> (which seems to look for a name followed by parentheses) is
> actually any better than the old.
I'm not too satisfied with the solution either. I've been thinking
about adding some important keywords such as for, while, if, until,
case etc, but decided it would be too much overkill. And, it still
woudln't work 'correctly' in a case such as this one you presented
above.
> 2. What would have printed before:
>
> @@ -1,2 +3,4 @@ foo() {
>
> now prints
>
> @@ -1,2 +3,4 @@ foo
>
> without the parentheses or brace. It looks like the similar C one
> keeps the parentheses, at least. I find that a bit more readable,
> as it is more clear that the line indicates a function, and not
> simply some top-level command.
Indeed. I'll change the regexp to include the parenthesis.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Skip archive --remote tests on Windows
From: Johannes Sixt @ 2011-08-03 10:40 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Jeff King, Git Mailing List, Erik Faye-Lund
In-Reply-To: <m3hb5yrhfw.fsf@localhost.localdomain>
Am 8/3/2011 11:09, schrieb Jakub Narebski:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> -test_expect_success 'archive --list shows only enabled remote filters' '
>> +test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
>
> Shouldn't the prerequisite be called FORK rather than NON_MINGW?
Yes, it should. But we already have one instance of NOT_MINGW in
connection with archive --remote in this file before this patch, and with
Erik's efforts, these particular prerequisites should go away anyway RSN.
-- Hannes
^ 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