It looks like we need to reorder two of the patches.
This patch needs to be moved to later in the series and happen after
the delete_ref conversion :
refs.c: make delete_ref use a transaction
refs.c: add an err argument to delete_ref_loose
I will respin a v19 with these patches reordered.
On 18/06/14 21:08, Jeff King wrote:
On Wed, Jun 18, 2014 at 08:52:46PM +0100, Ramsay Jones wrote:
[snip]
Yeah, I noticed it while writing the patch but decided it wasn't worth
the trouble to deal with (since after all, it's not advertised to any
callers, the very thing that sparse is
Jeff King p...@peff.net writes:
You can use a strbuf to build up a string from parts, and
then detach it. In the general case, you might use multiple
strbuf_add* functions to do the building. However, in many
cases, a single strbuf_addf is sufficient, and we end up
with:
struct strbuf
On 06/19/2014 12:27 AM, Ronnie Sahlberg wrote:
It looks like we need to reorder two of the patches.
This patch needs to be moved to later in the series and happen after
the delete_ref conversion :
refs.c: make delete_ref use a transaction
refs.c: add an err argument to delete_ref_loose
I have looked for an answer to the Error 128 Clone succeeded, but checkout
failed message we are getting on a clone command.
And there does not seem to be any that relates to our situation.
The repository is on a local file server system that is mounted to the pc as L:
If we clone the
I'm still working on the struct object_id patches, and I had a style
question. In several places throughout the code, we do something like
this:
unsigned char a[20], b[20];
/* do some stuff with b */
hashcpy(a, b);
I could implement an oidcpy that does the same thing.
struct object_id
On Wed, Jun 18, 2014 at 04:03:40PM -0700, warren.l.do...@tektronix.com wrote:
git.exe clone --progress -v L:\GIT_REPOSITORY L:\warrend\fail
Cloning into L:\warrend\fail
Done.
Fatal: unable to read Long hash key
Warning: clone succeeded, but checkout failed.
You can inspect what was
On Thu, Jun 19, 2014 at 12:11:43AM +, Dodge, Warren L wrote:
Hi Brian
Hi. Please do keep the list in CC. Someone else may be able to help
you better than I.
c:\Program Files (x86)\Git\bin\git.exe --version
git version 1.9.4.msysgit.0
I also had 1.8.?? and it did the same thing so I
Here is the fsck which is ok. Remember that if I do the clone to another file
server it works fine.
c:\Program Files (x86)\Git\bin\git.exe fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (774/774), done.
Checking connectivity: 5128, done.
One thing I
105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
on mkdtemp, which is not available on Windows.
Use the original temporary directory behavior when mkdtemp fails.
This makes the code use mkdtemp when available and gracefully
fallback to the existing behavior when it is not
On Mon, Jun 16, 2014 at 11:17:46AM -0700, Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
Hmm.. I guess what I could do is keep the old behavior (having gitk ignore
TMPDIR)
on Windows and only use the new code path on non-Windows.
Or perhaps attempt to create, catch error
Hi:
^_^
I did some test on the EOL behavior between official git and libgit2-based
software(TortoiseGit).
Then, I got that they have different EOL behavior.
The blob stored in repository is a text file with mixed EOLs.
Even set core.autocrlf = true, official git checkout the file as it is(means
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword` becomes
an alias for the command line `cherry-pick --edit`. The porcelain
`rebase--interactive`
Hi,
This patch series is part of the undertaking to add command line options
to to-do list commands. The goal is to be able to write something
similar to
pick --reset-author --signoff a Some changes
pick b Some more changes
squash --no-edit c Ack
`pick_one` and `pick_one_preserving_merges` are wrappers around
`cherry-pick` in `rebase --interactive`. They take the hash of a commit
and build a `cherry-pick` command line that
- respects the user-supplied merge options
- disables complaints about empty commits
- tries to fast-forward the
When `rebase` is executed with `--root` but no `--onto` is specified,
`rebase` creates a sentinel commit which is replaced with the root
commit in three steps. This combination of options results never in a
fast-forward.
1. The sentinel commit is forced into the authorship of the root
Rewrite `squash` and `fixup` handling in `do_next` using the atomic
sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or parametrized
`do_pick` and make the subsequent patch reimplementing `squash` in terms
of such a single function more readable.
Might
The options passed to `do_pick` determine whether the picked commit will
be rewritten or not. If the commit gets rewritten, because the user
requested to edit the commit message for instance, let `pick_one` merely
apply the changes introduced by the commit and do not commit the
resulting tree yet.
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect but
exiting the sub-shell with a failure exit status. Moreover, if `do_pick`
is called while a squash or fixup is happening, `die_with_patch` will
discard
Hi,
I was about to send a patch like this series today, I am attaching it below.
-- 8 --
Subject: [PATCH] imap-send: use skip_prefix instead of using magic numbers
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
imap-send.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff
101 - 121 of 121 matches
Mail list logo
