ntainer could adjust them when he picks up the patch). But
> there are just enough that it's probably worth making his life easier
> with a v3.
> You can put my Reviewed-by on it, too. :)
Here it is:
>8
From: Damien Robert
Date: Tue, 16 Apr 2019 14:16:46 +0200
Subject: [PA
pple effects of the test changes, since I think we'll end up
> changing them again to make sure ":trackshort" is distinct.
There are now less impactful than before because the master branch in the
test refers to the same commit as before; there is just a new commit for the
'myf
so that the upstream branch is ahead by 2 while the push
branch is ahead by 1, this allow us to test that %(push:track) refer to
the correct branch.
This change the expected value of some following tests, so update them
too.
Signed-off-by: Damien Robert
---
ref-filter.c| 7
ch in two, one
introducing `stat_push_info` in remote.c and the following one using it in
ref-filter.c
Damien Robert (1):
Fix %(push:track) in ref-filter
ref-filter.c| 7 ++--
remote.c| 78 +++--
remote.h| 2 ++
t/
epends on the state of the git repositories of previous tests rather
than creating the git repos from scratch (presumably for the sake of
speed), so I was afraid to break things. But I see that I can probably
reuse the repos from the test 'setupt for detecting upstreamed changes'.
So I'll try (when I have time...) to do a RFC implementation of a 'noop
fetch' approach. I first need to understand the source of fetch.c better,
in particular how to do something like store_updated_refs when we are doing
a noop fetch (so without using transports).
--
Damien Robert
http://www.normalesup.org/~robert/pro
>From Damien Robert, Mon 08 Apr 2019 at 16:53:40 (+0200) :
> > Others may have a better idea, but I do not immediately see any
> > solution better than inventing a new option to "git pull".
So here is a RFC patch that implements --no-fetch. (I am not sure about
the wor
not sure I understand what a no-op `git fetch` means exactly.
In the "git fetch; ; git pull" scenario,
after I do the real `git fetch` and want to merge/rebase the changes, how
would I prevent `git pull` to pull new commits that were pushed in between?
--
Damien Robert
feature be accepted?
--
Damien Robert
hint: You can disable this warning with `git config advice.ignoredHook false`
To allow the old use-case of enabling/disabling hooks via the executable flag a
new setting is introduced: advice.ignoredHook.
Signed-off-by: Damien Marié
---
Documentation/config.txt |
Thanks for the help, a new patch is coming with those fixes applied.
On Fri, Oct 6, 2017 at 7:53 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I think it is easier to reason about if this were not "else if", but
>> just a simple "if".
>
> And here are two small suggested changes to the
hint: You can disable this warning with `git config advice.ignoredHook false`
To allow the old use-case of enabling/disabling hooks via the executable flag a
new setting is introduced: advice.ignoredHook.
Signed-off-by: Damien Marié
---
Documentation/config.txt |
On Wed, Oct 4, 2017 at 6:40 AM, Junio C Hamano wrote:
> Damien writes:
>
>> ---
>
> Please explain why this change makes sense to those who find this
> commit in "git log" output six months down the line, without having
> read the original thread that motivat
---
Documentation/config.txt | 2 ++
advice.c | 2 ++
advice.h | 1 +
contrib/completion/git-completion.bash | 1 +
run-command.c | 4
5 files changed, 10 insertions(+)
diff --git a/Documentati
nfigured hook could be better.
At least as a warning to be backward-compatible.
Thanks,
Damien
Use of 'iff' may be confusing to people not familiar with this term.
Improving the --normalize option's documentation to remove the use of
'iff', and clearly describe what happens when the condition is not met.
---
Documentation/git-check-ref-format.txt | 6 +++---
1 file changed, 3 insertions(+)
rmalized refname is valid then print it to standard output
> and exit with a status of 0. Otherwise, exit with a non-zero status.
I'll submit a revised patch shortly, following your suggestion.
Cheers
Damien
---
Documentation/git-check-ref-format.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index 8611a99..377c85a 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-r
> A bot could subscribe to the list and create branches in a public repo.
> (This idea feels familiar -- didn't somebody attempt this already?)
Thomas Rast maintains git notes that link git commits to their gmane
discussion, you can get them with
[remote "mailnotes"]
url = git://github.com/tras
Felipe Contreras wrote in message
<5366db742d494_18f9e4b308aa@nysa.notmuch>:
> == git update ==
>
> Another proposed solution is to have a new command: `git update`. This
> command would be similar to `git pull --ff-only` by default, but it
> could be configured to do merges instead, and when doi
rent
branch.
- `git mystash info` gives informations about a stash.
So obviously not all of these would be good for inclusion into git, but
maybe some of them would be somewhat worth it. When I have the time I'll
try to write tests and send proper patches.
--
Damien Robert
--
To unsubscr
8<
>
> From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001
> From: Pete Wyckoff
> Date: Thu, 16 Jan 2014 18:34:09 -0500
> Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks
> MIME-Version: 1.0
> Content-Type: text/plain; ch
:00:00 2001
> From: Pete Wyckoff
> Date: Thu, 16 Jan 2014 18:34:09 -0500
> Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Damien Gérard highlights an int
On 16 Jan 2014, at 15:45, Pete Wyckoff wrote:
> Oh cool, that helps a lot. P4 is just broken here, so we can get
> away with being a bit sloppy in git. I'll try just pretending
> "empty symlinks" are not in the repo. Hopefully you'll have a
> future commit in your p4 repo that brings back bn.
On 16 Jan 2014, at 14:08, Pete Wyckoff wrote:
> dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
>> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
>> ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h
>> ... headAction edit
>> ... headType symlink
>> ...
On 15 Jan 2014, at 00:24, Pete Wyckoff wrote:
> p...@padd.com wrote on Mon, 13 Jan 2014 19:18 -0500:
>> dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100:
>>> I am trying to clone a perforce repository via git and I am having the
>>> following backtrace :
>>>
>>> {14:20}~/projects/:maste
rsion: git version 1.8.5.2.309.ga25014b [last commit from master from
github.com/git/git]
os : ubuntu 13.10
Any ideas ? :)
Best regards,
Damien--
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
e.comp.version-control.git/191835/focus=192464
--
Damien Wyart
--
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
e to know where you
> > were at and I can see if I can pick up where you left off (unless you
> > want to finish yourself).
Greetings
I was just wondering whether there been any progress on this topic since
last year... André ?
Cheers
Damien
--
To unsubscribe from this list: send
git init
git commit --allow-empty -m "init"
git checkout -b test
echo foo > foo
git add foo
git commit -am 'add foo'
git checkout master
echo 'Important data' > foo #[1]
echo foo > .gitignore
git checkout test
If I tried a `git checkout test` after [1], I would get the error message
error: T
Junio C Hamano wrote in message
<7v61vg9eht@alter.siamese.dyndns.org>:
> The "tutorial" was written in fairly early days of Git's history, in
> order to primarily help those who want to use the plumbing command
> to script their own Porcelain commands. As it says at the very
> beginning, the
Matthieu Moy wrote in message :
>> that confuses users.
>
> ... but I do agree that the doc is really confusing. It would be much
> better if the doc could be reduced to:
>
> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
> Please refer to the documentation of that co
ress robert@numenor.night-elves. I thought that putting:
Damien Robert
in the .mailmap would unify the two adresses, but it does not:
git shortlog -se
15 Damien Robert
266 Damien Robert
as you can see, the Damien.Olivier.Robert+git as been lowercased to
damien.olivier.robert, so I am forced
I would like to use git ls-files to show all the ignored files, including
directory.
As an example of setup:
mkdir /tmp/git && cd /tmp/git
git init
mkdir a b
touch a/a
touch b/b
cat >.gitignore << EOF
a/
b/*
EOF
Then if I do:
$ git ls-files --exclude-standard --ignored --others
b/b
$ git ls-file
Hi all,
I was wondering if you had any tips on the following workflow:
I work on an experimental feature branch of a project. I have some patches
that I implement in branch patch1 and patch2 on top of the feature branch.
I test if they both work together by merging patch1 and patch2 into a build
br
34 matches
Mail list logo
